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

Dalai Felinto dalai at blender.org
Tue Nov 17 18:50:51 CET 2020


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 feature in the
(dev branch of the) manual even before the patch is committed (proven that
its design itself was approved). I would even encourage this, given that
the alternative is the other way around.

Op di 17 nov. 2020 om 13:45 schreef Brecht Van Lommel via Bf-committers <
bf-committers at blender.org>:

> 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 that here:
> https://developer.blender.org/T73394
>
>
>
> On Tue, Nov 17, 2020, 10:28 Jeroen Bakker via Bf-committers <
> bf-committers at blender.org> wrote:
>
> > 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 can use a local branch/or copy for keeping track of changes to
> > bf-manual and pushes the changes together with the patch. Using the
> > scrum methodology the patches are a team responsibility and therefore
> > updating the manual is also a team responsibility. We would like to
> > update the manual side by side to the patches that land to make sure
> > that the manual is in sync with master.
> >
> > The manual is hosted on SVN what doesn't (have good) support for
> > distributed version control. In the short term we created a git
> > repository hosted outside of blender.org with the main reason to not
> > confuse manual writers.
> >
> > Using the scrum methodology with blender projects is still experimental,
> > but if it is successful more projects could adopt this methodology. It
> > would be good to know if the chosen solution is fine for the short term
> > (as part of the experiment). What might be issues that other writers
> > would see with our chosen solution?
> >
> > In the longer run we could see if we want to do some changes to our
> > current infrastructure. Taken into account the community efforts on
> > updating the manual and therefore the tactically choice to host the
> > manual in SVN.
> >
> > Regards,
> >
> > Jeroen Bakker.
> >
> >
> >
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > https://lists.blender.org/mailman/listinfo/bf-committers
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>


-- 

-Dalai-
--------------------------------------------------------------------
Dalai Felinto - dalai at blender.org - www.blender.org
Blender Development Coordinator
Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands


More information about the Bf-committers mailing list