Yes, I have a draft Local Labs discussion starter post sitting in my drafts folder. I wanted to double check the technology feasibility of different options before opening up the discussion.
david On Wed, Dec 3, 2008 at 2:12 PM, Bernie Innocenti <[EMAIL PROTECTED]> wrote: > This discussion seems better suited for [EMAIL PROTECTED] > > David Farning wrote: >> On Wed, Dec 3, 2008 at 11:17 AM, Ivan Krstić >> <[EMAIL PROTECTED]> wrote: >>> On Dec 2, 2008, at 7:53 AM, Bernie Innocenti wrote: >>>> The Wikipedia seems to be doing that. Let's ask some Mediawiki >>>> experts on IRC. >>> Wikipedia subdomains (country wikis) are _actually_ separate wikis. >>> They just use a single codebase on Wikimedia servers, and detect which >>> individual wiki to load based on the subdomain in the HTTP request. In >>> other words, this isn't really what we want, although it's a >>> possibility to set things up that way if we're OK with the increased >>> complexity. I think it comes down to how badly the local Labs want >>> translated MediaWiki sidebars. >>> >> Hey all >> I am going to try to reply to all question in one consolidated post. >> >> Interestingly everyone in the thread hit on the key issue; >> fragmentation vs. autonomy. As a general rule we want to allow, but >> not require, Local Labs to be as autonomous as possible. >> >> To a large extent, how to do an Sugar deployment is still an unsolved >> question. Thus we want to introduce as much parallelization as >> possible into the solution. On the other hand we want to reduce >> necessary redundancy as much as possible. >> >> One issue to look at is purpose of a Local Lab. At this point in our >> life cycle, the primary purpose is to provide the necessary >> infrastructure to encourage the formation of region support >> organizations. The Local Labs will most likely not generate much >> content that is of value to people outside their Local Lab. >> >> Several of the teams that I have spoken with would prefer their own >> wiki over a name space, mostly for reasons of ownership and identify. >> The consequence of not offering them their own country.sugarlabs.org >> name will be increased fragmentation as teams begin to create their >> own web presence. >> >> The best open source example of this is git and kernel development. >> The distributed nature of git actively encourages forking. If someone >> becomes angry or wants to take the kernel a different direction, that >> is fine. The balancing act is how to increase the value to >> stakeholders to keep their code in the main tree. >> >> 1. How about option of allowing the group forming the local lab to >> chose between country.sugarlabs.org or a name space on >> wiki.sugarlabs.org? I don't believe that we need to worry about >> setting up a translating infrastructure for Local Labs. Their content >> will be pretty language and region specific. >> >> 2. Mailing list. looks like a solved problem. >> >> 3. As autonomous as possible. >> >> david > > > -- > // Bernie Innocenti - http://www.codewiz.org/ > \X/ Sugar Labs - http://www.sugarlabs.org/ > > _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) [email protected] http://lists.sugarlabs.org/listinfo/iaep
