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.
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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > > wrote: > > > > > On Sat, Feb 27, 2016 at 10:22 PM, Sergey Sharybin < > [email protected]> > > > 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 < > [email protected] > > > > > > > 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 > > > >> [email protected] > > > >> http://lists.blender.org/mailman/listinfo/bf-committers > > > >> > > > > > > > > > > > > > > > > -- > > > > With best regards, Sergey Sharybin > > > > _______________________________________________ > > > > Bf-committers mailing list > > > > [email protected] > > > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > > > > > > > > > -- > > > - Campbell > > > _______________________________________________ > > > Bf-committers mailing list > > > [email protected] > > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > > _______________________________________________ > > Bf-committers mailing list > > [email protected] > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > > > -- > With best regards, Sergey Sharybin > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > -- Douglas E Knapp, MSAOM, LAc. _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
