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

[Campbell Barton]

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