[IAEP] wiki bot - a consolidated response

[David Farning]

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.

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.

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. 

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.

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/

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.
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.
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.
h.  Local partial replication of wiki.  I had not thought of this
before.  It seems potentially very useful.  Local deployments could use
wiki content from upstream to augment their local content.  I'm thinking
of a model similar to TV programing with syndicated and local content.
g.  Firefoxman - I gave Dfarning-bot a flag. All of my human work will
be done under Dfarning.  Have you worked with pywikipedia bot framework.

Thanks
Dfarning