As Sean and Martin point out the consequences of this decision extend past SoaS. The effects seem to centre on four levels:
1. Procedural. 2. Mission, Vision, and Values. 3. Operations. 4. SoaS the project. As we work through the levels, a pretty good decision _should_ emerge. Procedural-- As a general rule, decisions are made on public mailing lists. Once a consensus is reached on the lists, the consensus is presented to SLOBs for ratification. Occasionally, a SLOB will point out that we missed an important point.... Then we refine the decision and iterate through the process again. I apologize for any confusion about that. I did not realize that my dual roles as a member of the board and the guy who often works on building consensus would cause confusion. Hopefully, by not sitting on the board next term some of that confusion will clear up. Values-- While thinking about how to present this issue to the board for ratification, I keep coming back to the value. "The success and trust in Sugar Labs is premised on empowering and enabling rather than excluding." The questions becomes, "How do we make an official relationships between Sugar Labs and a project empowering and enabling to both parties?" and "How do we prevent an official relationship between a project and Sugar Labs from excluding other interesting projects?" Any thoughts? david On Tue, Sep 15, 2009 at 4:03 PM, Sebastian Dziallas <[email protected]> wrote: > Let me rephrase again, to make things clear. I'd love to hear an > "official" answer on this. Soon. > > Is the current SoaS going to be the primary way Sugar Labs distributes a > Sugar-centric GNU/Linux distribution? > > --Sebastian > _______________________________________________ > SLOBs mailing list > [email protected] > http://lists.sugarlabs.org/listinfo/slobs > _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) [email protected] http://lists.sugarlabs.org/listinfo/iaep
