[IAEP] IAEP Digest, Vol 28, Issue 18 Consider the SugarCreationKit DVD a Project?

Thomas C Gilliard satellit at bendbroadband.com
Sun Jul 11 13:09:37 EDT 2010


>
> ---------- 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."
>   
Question re Sugar Creation Kit DVD:
http://people.sugarlabs.org/Tgillard/SugarCreationKit-123.iso
http://wiki.sugarlabs.org/go/Sugar_Creation_Kit

-This is really a compilation of SL Content on a DVD
where does such a project fit in this spectrum of Projects?
It probably would have qualified under the previous Project Category:
"wiki pages bearing the [[Category:Project]] tag predating this proposal."
http://wiki.sugarlabs.org/go/Category:Project

It would be nice to get a left sidebar listing for the DVD.iso  and move 
it's location to Downloads from Tgillard

Tom Gilliard
satellit

A related situation exists for the ASLOxo.iso with .xo files for Drag 
Drop Installs:
http://wiki.sugarlabs.org/go/Features/Soas_V4/ASLOxo_Activity_Test_Table
http://people.sugarlabs.org/Tgillard/ASLOxo-3ss.iso
(This may depend on the .xo file format remaining one of the ways 
Activities are distributed)


> 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
>
>   


More information about the IAEP mailing list