I mentioned the phabricator wiki since wiki.blender.org seems to be only used for developer docs now, and so it could be potentially be replaced entirely. But as I said in the task, I'm not arguing that someone should spend the significant effort to do such a migration, and of course there would be various issues to work out.
On Sat, Feb 27, 2016 at 12:22 PM, Sergey Sharybin <sergey....@gmail.com> wrote: > Hi, > > I will strongly suggest to ignore Phabricators Wiki for the following > reasons: > > - 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. > > 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: > > - 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. > > > On Sat, Feb 27, 2016 at 2:26 AM, Campbell Barton <ideasma...@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@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > > > > -- > With best regards, Sergey Sharybin > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
