[IAEP] wiki bot - a consolidated response

[Marco Pesenti Gritti]

On Tue, Jun 3, 2008 at 11:10 PM, David Farning <dfarning at gmail.com> wrote:
> First, thanks for the critical analysis of what I am doing.  I was not
> sure of how to react to the subdued response of my other wiki changes.
> I wasn't sure if the silence was due to agreement or apathy about the
> wiki.

Personally I've been following your work and agreed with pretty much
everything you did... Keep it up :)

> Based on the healthy response to the bot topic I feel more comfortable
> about announcing a change then preceding after waiting about 12 hours
> for a response.
>
> 1.  I am interested in syncing templates between the wikis.  For those
> with limited wiki experience, template are basically functions which
> affect the look and feel of a wiki.  CjL has done a fair bit of work on
> the templates at http://wiki.sugarlabs.org/go/User:Cjl/Sandbox .
>
> 2.  I would like to figure out how to setup wikibots to take care of
> some of the house keeping tasks.  In keeping with the low floor, high
> ceiling metaphor, I would like to make sure that the wiki is easy to
> navigate and edit while being flexiable enough for advanced use.

These make sense to me.

> 3  What content to host where?  I think this was the root of most of the
> responses.  This decision has two components political and technical.
>
> 3a.  Technical.  This comes down to deciding who is going to be
> responsible for what content.  The scenario which seems workable:
>
> SugarLabs is to OLPC what Gnome is to Ubunutu.
>
> With regard to Sugar, SugarLabs handles:
> _all_ sugar development,
> _upstream_ bug tracking,
> _limited_ end user support.
>
> With regard to activities, SugarLbs handles:
> _all_ api documentation,
> _all_ UI guidelines,
> _research and best practices_ for creating constructionist activities,
> _mechanisms_ for sugar coating and sugarizing third party activities,
> _foster_ ecosystem for developing third party activities,
> _maintain and document_  a limited number of critical activities.
>
> With regard to deployment:
> _No_ direct deployment support, (stay above the distro and hardware
> wars),
> _offer_ support for organizations who do deployments.

Sugar Labs "responsibilities" are still being defined but this looks
pretty sane to me.

> 3b. Political.  In my mind the most important issue is that Walter
> Bender has publicly expressed his support for OLPC and Chuck Kane has
> publicly expressed his support of SugarLabs.  Thus we can think of
> Sugarlabs as being spun off from OLPC.

Agreed.

> With regard to poaching:
> I do _not_ under any circumstance give the impression of poaching from
> the OLPC community or the hard work they have put into their wiki. This
> can be a bit like the hallway conversations.  Without clear conversation
> we can unintentionally cause resentment.
>
> Mechanism:
> Announce the intention to start moving content on sugar@ mailing list.
>
> /start loop/
>  work with olpc wiki representative to decide on topic to port.
>  select pages to move.
>  announce specific pages to move on sugar@
>  wait 24 hours for community response.
>  move pages.
> /end loop/


I'll just mention that the sugar related part of wiki.laptop.org is
quite a mess. I would do some refactoring while moving stuff.

> 4 Specific questions.
> a. This is half baked idea - I haven't even figured out how to turn the
> oven on;)
> b.  Who maintains what - Hopefully the synced pages will only be
> templates.  As the templates are synced, they will receive a comment
> stating that they are read only with a link to the original page.
> c.  Users manual. Sugar Labs maintains a generic users manual which
> distros can customize for their own use.

I'm not sure if this is necessary. The documentation for GNOME
applications for example is kept with the upstream project. Perhaps
the distribution manuals should just link to the sugarlabs one.

> d. Inherent deficiencies of centralized wikis. -- put on back burner.
> f. Who maintains what packages? decided as part of 3a.  ssh acess i'll
> defer to the infrastructure team.

You mean code packages? Maintainers are (or was) listed on the Modules page.

> g.  Creating APIs from source. We should look to gnome for ideas.  They
> produce really good APIs from their source code. Alas, i think it is a
> custom system.  But, with the large gnome community I would not feel
> uncomfortable using their system.

GNOME uses gtk-doc which only works well for C GObject. I think we
should use pydoc or similar for most of Sugar. (Bernie was mentioning
to me an alternative system which would also work for non-python code
but I forgot what it was and not yet evaluated it).

If someone can help out with this it would be great. I know that Tomeu
and others would be glad to put more documentation in the code, once
we have automatic docs generation setup.

Marco