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

[Campbell Barton]

On Sun, Feb 28, 2016 at 6:40 AM, Knapp <magick.crow at gmail.com> wrote:
> I am also one that wanted to make small edits but decide not to deal with
> the overhead. I got luck and now I just send bug reports to Aaron Carlisle
> and he fixes it for me but clearly not everyone will have this option.

This is not luck - if you find an error in the docs,
report a bug. These have been getting fixed.

> Wikipedia has a system where the edits can be checked by an editor before
> they are committed. Seems to me to be a good system and it clearly works.
>
> On Sat, Feb 27, 2016 at 4:45 PM, Sergey Sharybin <sergey.vfx at gmail.com>
> wrote:
>
>> So the actual issue is a lack of coordination work for contributors and the
>> reason why Manual is still in a reasonable shape is simply only because all
>> the contributors are scared away and now it's 1.5 people only working on
>> it.
>>
>> f we'll do better coordination work, then Wiki documentation will not be a
>> disaster at all.
>>
>> On Sat, Feb 27, 2016 at 4:41 PM, Aaron Carlisle <carlisle.b3d at gmail.com>
>> wrote:
>>
>> >  > IMO the new Sphinx-based solution presents too much of an initial
>> > > barrier to entry.
>> >
>> > This may be true and first however, once the environment gets setup
>> > It is really easy especially if you are using a GUI SVN client like Smart
>> > SVN
>> > In order to look at this correctly you need to see the arguments from
>> both
>> > sides.
>> > These can be found on the new manual [1]. One of the reasons for the wiki
>> > disaster
>> > Is that too many people would edit which resulted in some bad content
>> > and over redundant text.
>> >
>> >
>> > 1. https://www.blender.org/manual/about/migration.html
>> >
>> >
>> > On Sat, Feb 27, 2016 at 10:34 AM, Campbell Barton <ideasman42 at gmail.com>
>> > wrote:
>> >
>> > > On Sat, Feb 27, 2016 at 10:22 PM, Sergey Sharybin <
>> sergey.vfx at gmail.com>
>> > > wrote:
>> > > > Hi,
>> > > >
>> > > > I will strongly suggest to ignore Phabricators Wiki for the following
>> > > > reasons:
>> > > >
>> > >
>> > > It was mentioned as a possible alternative.
>> > >
>> > > > - It is not nearly as comprehensive as Mediawiki
>> > > > - Editing policies in Phabricator are still quite limiting, meaning
>> > > > granting someone's editing role for Wiki would either mean we
>> manually
>> > > > control this (which is same as current "Please mail us if you need
>> Wiki
>> > > > access" bullshit), or we'll effectively allow everyone to edit any
>> > object
>> > > > in our tracker which is not acceptable.
>> > > > - There's no comprehensive anti-spam tools in Phabricator.
>> > > > - Search is kinda pathetic
>> > > >
>> > > > Only argument for the Phabricator's wiki i currently see is that you
>> > only
>> > > > need one developer account to do the code and documentation. The
>> truth
>> > > is:
>> > > > _any_ current developer has a Wiki account, yet it does not help
>> > keeping
>> > > > documentation in an up-to- state. So the issue of out-of-date
>> > > documentation
>> > > > is clearly somewhere else. (and if it's really an account issue, we
>> can
>> > > > teach wiki.b.o to login with dev.b.o accounts).
>> > > >
>> > > > Let me ask this question: why would we keep diverging documentation
>> > from
>> > > > one single place (which is wiki.b.o) to a multiple ones (currently
>> it's
>> > > > b.o/manual, and also proposed move of developer's documentation
>> > somewhere
>> > > > else)? I don't see such a diverge making documentation any easier to
>> > find
>> > > > or any easier to maintain.
>> > > >
>> > >
>> > > We don't - and think using a wiki for developer docs is reasonable to
>> > > stick with.
>> > >
>> > > > I do see however bullshit happening on current wiki.b.o, all this
>> > > anti-spam
>> > > > things which are done in really lazy way. But that only means our
>> wiki
>> > > > itself is to be changed. Truth here is, it's a _really_ old mediawiki
>> > > > install which is just getting rotten. We can not upgrade it easily
>> > > because
>> > > > of the tree navigation, which required hacks all over the code. As
>> for
>> > > me,
>> > > > we should evaluate such proposal instead:
>> > > >
>> > >
>> > > The way we handle Wiki accounts is quite broken,
>> > > for a while I was getting mails from `wiki at blender dot org`,
>> > > and we got regular mails with people who wanted to just learn Blender,
>> > > where I'm not even sure they knew what the wiki account was for.
>> > > Sometimes their English was poor so it wasn't really clear why they
>> > > wanted access.
>> > >
>> > > > - Re-consider navigation in Wiki, avoid having hacks to try support
>> > > > navigation which was barely useful
>> > > > - Prepare fully fresh install of Wiki (new engine, new web server
>> > > settings
>> > > > optimized for today's standards and so on)
>> > > > - Install skin which we'll find acceptable (this is the most tedious
>> > > work,
>> > > > we'll need someone to work on the skin and it's not so simple for
>> > > Mediawiki
>> > > > i've heard)
>> > > > - Migrate the content to a new Wiki
>> > > > - Re-evaluate state of the documents in there, wipe out-of-date ones
>> > > >
>> > > > Benefits:
>> > > >
>> > > > - This keeps use of documentation the same as it always was
>> > > > - This does not scare actual editors with wither fully offline
>> editing
>> > > > - Let's everyone (new developers, old develeoprs, non-developers) to
>> > have
>> > > > project/design proposals in there, which are then simple to move to
>> an
>> > > > actual documentation/release notes
>> > > > - Keeps release notes, release cycle, ongoing projects, personal
>> > > > notes/design proposal/drafts in a single place.
>> > > >
>> > > > Simplified proposal: we can just ignore all history in existing Wiki
>> > and
>> > > > simply start a new one. Even with a default skin it will not be less
>> > > usable
>> > > > than default sphinx/phabricator wikis.
>> > > >
>> > > > In any case, we would _have_ to update wiki sooner than later, and it
>> > > will
>> > > > bring it back to an usable state. Now, please stop for a moment from
>> > all
>> > > > your "let's split stuff apart" proposal and outline _actual_ problems
>> > > which
>> > > > _can not_ be solved in a context of having fresh and working
>> wiki.b.o,
>> > > what
>> > > > will be the benefits of that move and so on.
>> > >
>> > > +1 (and something we've discussed/agreed on informally).
>> > >
>> > > > On Sat, Feb 27, 2016 at 2:26 AM, 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
>> > > >>
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > With best regards, Sergey Sharybin
>> > > > _______________________________________________
>> > > > Bf-committers mailing list
>> > > > Bf-committers at blender.org
>> > > > http://lists.blender.org/mailman/listinfo/bf-committers
>> > >
>> > >
>> > >
>> > > --
>> > > - 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
>> >
>>
>>
>>
>> --
>> With best regards, Sergey Sharybin
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>
>
>
> --
> Douglas E Knapp, MSAOM, LAc.
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers



-- 
- Campbell