[IAEP] [SLOBs] What are the rights and responsibilities of a SL project?

[Mel Chua]

 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