[Bf-docboard] Wiki meeting topics

[Nkansah Rexford]

I think I'm cool with Ton's point 1. The idea of admins are a good thing

And as regards the old docs about 2.5x, taking them away is a nice thing
too.

Some weeks ago I signed up to help o  that but got crashed up with work.

Will get back to it as soon as possible
On Jan 25, 2013 2:29 PM, "Ton Roosendaal" <ton at blender.org> wrote:

> Hi all,
>
> Lots of activity on this list! I can't be involved daily unfortunately,
> but it's a good practice for open/free projects to facilitate and empower
> the people who do the actual work. :)
>
> I would like to come back to a proposal I sent out some months ago. Text
> copied below. Keep reading, there's also more stuff!
>
> 1) Admins
>
> We could re-establish here a similar structure as we tried in past - and
> what we do for the developers; appoint and empower an admin board of 3 to 5
> people.
>
> The admins will typically not have to do a lot, but will help defining
> decisions (when the team has no consensis) and be an inspiring & positive
> force to make sure Blender's wiki keeps being cool to work on! The admins
> can also be representing wiki to other teams (to BF, at blender.org,
> conferences, etc).
>
> In no way this is meant as a special status, nor is it showing more
> appreciation as for the other volunteers; the roles are there to make sure
> everyone in the wiki team can function optimal.
>
> Based on current activity and what I've been advised, I propose:
>
> Admins:
> Kesten Broughton
> Brendon 'meta-androcto' Murphy
> Ivan 'greylica' Paulos Tomé
>
> Other tasks:
> Dan McGrath can assist as system admin
> Francesco Siddi as graphics designer (skins, layout)
>
> All open for discussion or feedback.
>
> 2) Wiki focus
>
> - Cleanup of old docs
>
> Since 2.50 we've keept most of the UI and features compatible though, and
> that's not going to change for 2.6x versions either. Also plans for 2.7x
> and later might not going to change Blender as much as we had for 2.5.
>
> For that reason, a first simplification of wiki would be kick out (hide)
> old docs. The introduction of separate 2.5 and 2.6 tagged docs is confusing
> too. A doc is either 'current' or 'outdated'.
>
> - Limit structure to minimum
>
> Formatting guidelines and templates and fancy wiki features should help
> editors, to make work on wiki more pleasant, accessible, and efficient (in
> that order :).
> We can only get a good wiki with a large and enthusiast team. Add
> structure and conventions only as a means to manage cases when too much
> user activity is requiring it.
>
> - Wiki is just a wiki
>
> A good doc is a bare-bones, giving a simple and understandable description
> of what a function in Blender does, and how to use it. Just like how you
> end up on wikipedia looking up a fact, Blender wiki is just our collective
> memory where you find stuff.
> Ideally you could just land on a page via a button tip in Blender.
>
> Secondary - maybe kept separate - tutorials can get space too. But I would
> suggest to limit that.
>
> 3) Blender Foundation support
>
> We do get donations and some sponsoring in, very regular even. I'm still
> struggling with all expenses though, and my preference is to (also) keep
> our development support at a high level.
>
> I'm always open for ideas how to (financially) support work for our
> docboard team though. This could also be via book contracts (either BF
> publishing or a 3rd party publisher).
>
>
> Thanks,
>
> -Ton-
>
> ------------------------------------------------------------------------
> Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
>
> _______________________________________________
> Bf-docboard mailing list
> Bf-docboard at blender.org
> http://lists.blender.org/mailman/listinfo/bf-docboard
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-docboard/attachments/20130125/b3ffb546/attachment.htm