[Bf-committers] Blender developers meeting minutes - February 27, 2016

Joshua Leung aligorith at gmail.com
Sat Feb 27 14:09:32 CET 2016


Just adding another voice to the fray:

* I agree with Sergey + Ton's concerns regarding the way that
documentation/manuals/wiki are currently split into several different
systems:
  - IMO the new Sphinx-based solution presents too much of an initial
barrier to entry. (Personal experience: When I saw the amount of setup work
I'd need to do to get a working doc-editing environment set up for what may
have amounted to a short 1-line fix, I just gave up... there were simply
other more pressing matters to attend to, in the time/effort that getting
all that set up would have required) Even if we don't completely abandon
the ability to do offline edits, for starters, it would be nice to have a
web-based interface for such "casual edits" to be made.

  - Sergey's point/idea of making some kind of unified login for Phab +
Wiki (otherwise known as: Wiki should be able to use existing dev/tracker
ID's, saving everyone the permissions-requesting dance) is also
interesting, and something that may be worth further investigation
(provided it isn't going to be too much of a distraction to put in place).
It's somewhat crazy that we have two different systems for maintaining
documentation-like stuff. I'd like to see some consolidation here again.


* During the meeting, Campbell raised the point that the "Page Versions"
stuff that we have in the Wiki has turned out to be quite a failure. I have
to agree that this did have quite a few rough edges.  However, I bring this
up mainly as this concerns another issue regarding the state of our
documentation...  Edits to documentation can fall into 2 categories:

 1) Correcting incorrect/incomplete information about the documentation for
an existing feature that hasn't changed in the current version, or which
was changed in an earlier version

 2) Documenting some new features or changes to behaviour that are
available in master/branches, but not necessarily in the latest
official/stable release

The question(s) I suppose then are related to what the "live" state of the
documentation should show: The state for a previous stable release (and
with or without any corrections/errata subsequently added - e.g. 1), the
state for the current dev version only (e.g. previous stable + 1 + 2) and
have backups for the older versions,  or something else entirely?  In a way
I supposed the Sphinx workflow kindof has an advantage over the current
Wiki in that docs can also be developed in a similar way, and only
"generated" for release alongside another official build.


* Howard also brings up some valid points:
  - Notably, the image management facilities of Mediawiki (or rather, the
version we use now - I'm not sure if things have improved at all in the
newer versions) means that it is a pain to insert any images there. This is
admittedly a very big reason why I often dread having to prettify release
logs and/or having to edit the old docs.  Phab's handling of this is quite
nice (though I have encountered a problem where it does refuse to re-upload
an edited copy of the same file, at least within the same edit session).

  - Also, yes, making docs is a pain. But, at least I finally started
getting around to jotting down some notes/checklists on doing some rather
"standardised" additions that require edits in multiple places (especially
since a few of these are particularly error-prone - e.g. ID, AnimData,
Circle Select, New Toolsetting Defaults). See
http://wiki.blender.org/index.php/Dev:Source/Architecture#Developer_Checklists






On Sun, Feb 28, 2016 at 1:28 AM, Howard Trickey <howard.trickey at gmail.com>
wrote:

> I just wish whatever we had were as easy to write documentation *with
> diagrams* in as, say, Google Docs. (I know, Google Docs doesn't have a
> linking structure that would make it suitable for what we are talking about
> here, but it does have reasonable diagramming and image insertion tools.) I
> found it quite tedious doing this:
> http://wiki.blender.org/index.php/Dev:Source/Modeling/Bevel . But wish
> more
> developers would spend time doing it about areas where we have to explore
> design tradeoffs and algorithms. And, I suppose relevant to this
> discussion, that Bevel documentation is a bit out of date now, partially
> because it is annoying to make new pictures in our current wiki system.
>
> - Howard
>
> On Sat, Feb 27, 2016 at 7:14 AM Ton Roosendaal <ton at blender.org> wrote:
>
> > Hi,
> >
> > > - @Blendify proposes to migrate developer documentation to new system
> > >  (and help with the migration),
> > >  https://developer.blender.org/T47563
> >
> > Seriously? I would rather discuss to move manual back to wiki one day.
> > The manual procedure we have now scares away nearly everyone who would
> > consider to help.
> >
> > I'd don't see evidence that Sphinx will work to get more people
> contribute
> > to Blender docs. It's really great to see 1 or 2 people contribute there
> so
> > much, but you cannot call it a community project...
> >
> > -Ton-
> >
> > --------------------------------------------------------
> > Ton Roosendaal  -  ton at blender.org   -   www.blender.org
> > Chairman Blender Foundation - Producer Blender Institute
> > Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
> >
> >
> >
> > > On 27 Feb, 2016, at 2:26, Campbell Barton <ideasman42 at gmail.com>
> wrote:
> > >
> > > Hi, here are the notes from today's meeting in irc.freenode.net
> > #blendercoders.
> > >
> > > 1) Upcoming release
> > >
> > > So far things go smooth with 2.77rc1, reminder that release notes need
> > > attention still.
> > >
> > > - Mike Erwin will do OpenGL release notes.
> > >
> > >
> > > 2) Current projects
> > >
> > > - Developers confirm that after 2.77 we should *stop* focusing
> > >  on 2.7x and move attention to bigger 2.8x projects.
> > >  However discussion shows we still need more concrete planning.
> > >
> > > - UI team will start having its own meetings,
> > >  current plan is to hold after next developer meeting.
> > >  Will be announced on the bf-committers mailing list.
> > >
> > > - UI project has _many_ open tasks with discussion and no conclusion,
> > >  these tasks could use some decisions from UI design leads.
> > >  (or archive if theirs no clear outcome and nobody has time for them).
> > >
> > >
> > > 3) Other Projects
> > >
> > > - Kevin Dietrich has begun work on the DwarfLabs Alembic patch,
> > >  plans to move development to a branch and update to support
> > >  import/export based on suggested changes in review.
> > >  https://developer.blender.org/D1783
> > >
> > > - @Blendify proposes to migrate developer documentation to new system
> > >  (and help with the migration),
> > >  https://developer.blender.org/T47563
> > >
> > >  However others in meeting prefer further discussion
> > >  on mailing list before going ahead and making changes
> > >  (evaluate Phabricator's Wiki for developer docs for eg).
> > >
> > > --
> > > - Campbell
> > > _______________________________________________
> > > Bf-committers mailing list
> > > Bf-committers at blender.org
> > > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>


More information about the Bf-committers mailing list