From the last SLOBs agenda-kicking, http://lists.sugarlabs.org/archive/iaep/2010-July/011343.html:
What are the rights and responsibilities of a SL project?" (This should be a simple answer, but we need to agree on the same simple answer.) Right now, we have http://wiki.sugarlabs.org/go/Sugar_Labs/Project_Guidelines. The current page says projects start as SIGs, then apply to SLOBs for project status. It's not clear what that project status grants them (there's pretty much nothing on this except for "name/logo usage" - no mention of, for instance, infrastructure privileges or being listed on the sidebar) and also not clear what responsibilities projects have Is this topic actually blocking anyone? I'd like to propose a motion (throwing out a strawman here, with the intent that folks will make it better): ---------- MOTION ----------- First, the short version: 1. If your project helps SL, is all freely licensed, and has a wiki page with certain info on it, you can apply for project status by emailing slobs/iaep your wiki page URL and saying "here's our project page, please raise a motion to make us a project." 2. If SLOBs passes the motion (4 votes of +1), you are a project. This gets you a sidebar listing, do-it-yourself infrastructure access, and permission to call yourselves a SL project. 3. Projects are obligated to update their project page and email that project page URL to the list during the last month of each Sugar release cycle. That's it. 4. If a project doesn't do this (SLOBs will check), its project status is revoked, and it loses the sidebar listing and the ability to call itself a SL project. Projects who have their status revoked may reapply, see (1). Now, the fine print: Being a SL project means you get (1) listed in the sidebar, (2) full use of SL infrastructure's resources (though projects must do the administrative work themselves, they'll get machine access) if the project isn't already using them, and (3) permission to refer to yourselves as a SL project (you can request TM usage separately). Being a SL project does NOT mean that (1) SL teams are obligated to fulfil all your requests, or that (2) SLOBs or SL teams can tell you what to do, or that (3) anyone else will step up and make your project happen - people working on a project still need to step up and drive and do all the work. The only thing SLOBs can do is remove "SL Project" status, which (1) removes a project from the sidebar and (2) the project not being able to refer to itself as a "SL project" any more. (Infrastructure privileges shouldn't be removed except in cases of gross misconduct.) SL projects must: * work towards the mission of SL in some way, http://wiki.sugarlabs.org/go/Sugar_Labs#Mission * contain only code and content released under approved licenses, http://wiki.sugarlabs.org/go/Trademark#Approved_licenses To request status as a SL project, create a project wiki page that contains (at minimum) the following information, and submit it to SLOBs as an agenda item ("here is our project wiki page, can we be a project?") (these are directly from the version of http://wiki.sugarlabs.org/go/Sugar_Labs/Project_Guidelines as of this writing) * Who the new project would serve and who will lead the project * What the goals and scope of the new project would be * When the project can be considered a success * Where the project will lead and where it will fit into Sugar Labs * Why the idea warrants the creation of a new project within Sugar Labs * How the project will benefit Sugar Labs and the Sugar ecosystem * The number of active contributors * The state of the project compared to its goals * Documentation of how the project is working for the community * The current method of governing the project * A schedule and plan to achieve remaining goals and milestones This then becomes a motion that needs 4 SLOBs +1s to pass, just like any other motion. The only obligation of a project is to submit a status report, in the form of emailing iaep a link toan updated project wiki page with up-to-date answers to all the same above questions, during the last month of each sugar release cycle. One week after each Sugar release cycle, SLOBs will check which projects have fulfilled that obligation, renew the project status of all projects that have, and revoke project status of all projects that haven't. Projects that haven't can simply reapply. ------------ How reasonable does this sound to everyone? Amendments? Changes? If you want to make substantial edits, please throw this on a wiki page and send us all the link. ;) --Mel _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep