Re: [Bf-committers] Patching the manual as a team responsibility

2020-11-17 Thread Aaron Carlisle via Bf-committers
Hi, I think what Jeroen is getting at is that SVN's branching support makes it hard to use the scrum methodology. While it is possible with SVN I think SVN just really is not cut out for the intricate merging that needs to be done. Migrating the bf-manual repository to Git has been brought up

Re: [Bf-committers] Patching the manual as a team responsibility

2020-11-17 Thread Dalai Felinto via Bf-committers
Hi, I think the main issue is that the geometry-nodes project will end up updating the manual for things that won't be in master just yet. But given that those features are features that are indeed planned for master, it may be ok. I would go as far as saying that it should be ok to have a

Re: [Bf-committers] Patching the manual as a team responsibility

2020-11-17 Thread Brecht Van Lommel via Bf-committers
Developers are already welcome to document their features in the manual, I don't think this is any different? You do have to be aware that the manual tracks the release branch while it exists, not master. Moving the manual to git and using branching would make that easier, there's a task for

[Bf-committers] Patching the manual as a team responsibility

2020-11-17 Thread Jeroen Bakker via Bf-committers
Hi all, In the geometry nodes project we are using the scrum methodology. We are currently performing a sprint that will commit new multiple small features to master. As part of this we are updating the manual. In the non-scrum way of development the developer who is responsible for a patch