10,579
edits
Changes
Jump to navigation
Jump to search
Oversight Board/2008/Meeting Minutes-2008-06-30 (view source)
Revision as of 18:50, 1 July 2008
, 18:50, 1 July 2008New page: ==Sugar Labs meeting== Monday, 30 June 2008 Via Monte Napoleone, Milano, IT Attending in person: Marco Pesenti Gritti, Paul Noja, Tomeu Vizoso, Walter Bender, Carlo Falciola, Franco Lod...
==Sugar Labs meeting==
Monday, 30 June 2008
Via Monte Napoleone, Milano, IT
Attending in person: Marco Pesenti Gritti, Paul Noja, Tomeu Vizoso, Walter Bender, Carlo Falciola, Franco Lodato, Luca Ferrari, Karen Sandler
Participating by IRC: bernie, mostro, mk8, BryanWB, arjs, shenki, jg, cjb, reed, dwmw2, mtd, walter, marcopg
==Governance and the Software Freedom Conservancy===
Karen led a discussion about the implications of Sugar Labs joining the Conservancy. The SFC is a home for FOSS projects as an umbrella organization: FOSS projects become part of the Conservancy; they get tax-free status in the US; and the projects set up a day-to-day governance structure that is generally autonomous.
Shenki asked a question regarding any downsides. While there is always a unilateral mechanism to spin out from the Conservancy, by joining, (1) we would be making a committed to remain a non-profit organization in regard to any project asset (funds that we might raise, any copyrights or trademarks we might own); (2) no projects have ever spun out on their own, so there may be some unknown obstacles; and (3) there would be some administrative oversight (but we need it from somewhere).
The Conservancy has some concern that Sugar Labs might get so big as to incur too big of a burden for the Conservancy to pick up all administrative expenses without some mutually agreed mechanism of help from Sugar Labs.
Sugar Labs must designate one or two people to be the central point for communicating with the Conservancy regarding expenditures, reimbursements, etc. handled by the Conservancy on our behalf.
Joining the Conservancy means a commitment to both FOSS and non-profit status. However, there is and should be room for for-profit entities to grow up around Sugar Labs, offering support, extra services, such as ports, etc.
A question was raised in regard to working outside of the United States (the Conservancy is a US-based 501(c)(3)); while it hasn't been a problem, if necessary, projects within the Conservancy can work with organizations elsewhere—e.g., the Conservancy could help with administration of non-US programs without having to be involved in the funding—money can be raised and stay local, under local laws.
Karen made some in-line edits (mostly in the form of questions) to the Governance page in the wiki. We need to achieve a bit more clarity about a few topics, such as initial membership, terms of office, voting mechanics, etc. as part of the process of joining the Conservancy.
===What are we (Sugar Labs) trying to accomplish?===
Sugar Labs is the focal point for a community project that is providing the engineering and support for Sugar, a FOSS project that is designed to facilitate a collaborative and reflective set of learning activities. Sugar Labs is the upstream maintainer for the work and helps to promote it, but the development work itself is done downstream, in the community, both by volunteers and groups that want to offer services, in some cases for profit. There was consensus that Sugar Labs should manage the release process and the review process.
Bryan posited that the “conceptual integrity” and quality control of Sugar as a product needs to be maintained by Sugar Labs, but that Sugar Labs shouldn't try to constrain the educational approaches used by schools.
Shenki asked how OLPC and RedHat fit in. OLPC (and other platform providers) are downstream and should be pushing patches up to Sugar Labs, making their needs and point of view known to the community. We (the Sugar community) should strive to make our code work for everyone, not just OLPC, so that there is a broader context for support.
It was suggested that we set up a page in the wiki to let people advertise engineering and support services.
===Sugar distributions: what are the issues?===
The bulk of the discussion revolved around what are the best forms of distribution to facilitate people trying Sugar (and if they like it, installing it). We discussed targeting old Windows computers that might be in a school, for example—a version that teachers and students can use.
Carlo suggested that we make a matrix that explains more clearly what you get/don't get from different distribution models, such as a LiveCD, QEMU, etc. It was suggested that distributing Sugar on a USB image is perhaps the best option, since it lets you install additional activities, save files, etc.
Another topic was the need for better documentation: for example, the Sugar session on Ubuntu: Lot of undocumented little details, such as you cannot log out, so you need to either restart X (Ctrl-Alt-Backspace) or do a reboot (from the shell or the Homepage menu); and that you can copy activities directly into ~/Activities. The FLOSS Manuals project has offered to help with documentation; we are considering using the existing Trac system for documentation requests, bug reports, etc.
===Sugar Labs look and feel: a graphic design review===
Luca Ferrari and Franco Lodato presented some designs for a “corporate identity” for Sugar Labs. The designs will be posted in the wiki for feedback. (Karen pointed out the importance of trademarks with in the context of FOSS projects.)
===Sugar on mobile phones: is it possible? does it make sense?===
We also had a discussion about mobile devices. This is a topic that has been raised repeatedly in recent months and, while it doesn't seem to have a direct connection to Sugar's educational goals, it does seemingly broaden the developer community for Sugar (“growing the community”) and bring more people into the circle of collaboration with learners using Sugar-enabled devices.
Further, Sugar would probably make a pretty decent phone interface, especially in light of its clarity of design and its collaborative model.
Still, it was argued that a cellphone screen is a bad environment for learning and that it would not be a substitute for a laptop. Chris Ball asked, “What are the minimum requirements for expressiveness and learning when we work on a port of Sugar?”
We had some discussions about what would be involved in such a port and whom might be interested in doing it. (The Nokia 8000 was suggested as a possible point of departure.)
===Sugar Labs: models of support===
This was in part a continuation of the discussion about purpose. The issue of long-term stability—both perception and reality were discussed: up-take of Sugar will be increased if there is a sense that it is going to be here and supported for the long run. It was argued that we need to help establish local and regional champions, ownership, and support.
:In “biologically inspired” architectures one is much more interested in how the organism and ecologies of them are to be sustained, and how the dynamical systems can be understood, fixed, changed, evolved, reformulated, etc., while they are running and with the help of tools that work within them. Just as a cell, and especially e. g. a human baby, is not made by hand, we are more interested in making growth processes that can be influenced with far more ease than direct construction. So, most objects are made by other objects acting under conditions that include the dynamic state in which they will become part of the ecology. —Alan Kay
What are the Sugar growth processes?
===Fund-raising: how much and from whom?===
We didn't really get into this topic in any detail accept to agree that order 10s of thousands of dollars would probably be adequate for currently anticipated needs: meeting support, outreach, etc.
We do need to discuss what venues would be useful in light of reaching both the developer and user (primarily learning) communities.
Monday, 30 June 2008
Via Monte Napoleone, Milano, IT
Attending in person: Marco Pesenti Gritti, Paul Noja, Tomeu Vizoso, Walter Bender, Carlo Falciola, Franco Lodato, Luca Ferrari, Karen Sandler
Participating by IRC: bernie, mostro, mk8, BryanWB, arjs, shenki, jg, cjb, reed, dwmw2, mtd, walter, marcopg
==Governance and the Software Freedom Conservancy===
Karen led a discussion about the implications of Sugar Labs joining the Conservancy. The SFC is a home for FOSS projects as an umbrella organization: FOSS projects become part of the Conservancy; they get tax-free status in the US; and the projects set up a day-to-day governance structure that is generally autonomous.
Shenki asked a question regarding any downsides. While there is always a unilateral mechanism to spin out from the Conservancy, by joining, (1) we would be making a committed to remain a non-profit organization in regard to any project asset (funds that we might raise, any copyrights or trademarks we might own); (2) no projects have ever spun out on their own, so there may be some unknown obstacles; and (3) there would be some administrative oversight (but we need it from somewhere).
The Conservancy has some concern that Sugar Labs might get so big as to incur too big of a burden for the Conservancy to pick up all administrative expenses without some mutually agreed mechanism of help from Sugar Labs.
Sugar Labs must designate one or two people to be the central point for communicating with the Conservancy regarding expenditures, reimbursements, etc. handled by the Conservancy on our behalf.
Joining the Conservancy means a commitment to both FOSS and non-profit status. However, there is and should be room for for-profit entities to grow up around Sugar Labs, offering support, extra services, such as ports, etc.
A question was raised in regard to working outside of the United States (the Conservancy is a US-based 501(c)(3)); while it hasn't been a problem, if necessary, projects within the Conservancy can work with organizations elsewhere—e.g., the Conservancy could help with administration of non-US programs without having to be involved in the funding—money can be raised and stay local, under local laws.
Karen made some in-line edits (mostly in the form of questions) to the Governance page in the wiki. We need to achieve a bit more clarity about a few topics, such as initial membership, terms of office, voting mechanics, etc. as part of the process of joining the Conservancy.
===What are we (Sugar Labs) trying to accomplish?===
Sugar Labs is the focal point for a community project that is providing the engineering and support for Sugar, a FOSS project that is designed to facilitate a collaborative and reflective set of learning activities. Sugar Labs is the upstream maintainer for the work and helps to promote it, but the development work itself is done downstream, in the community, both by volunteers and groups that want to offer services, in some cases for profit. There was consensus that Sugar Labs should manage the release process and the review process.
Bryan posited that the “conceptual integrity” and quality control of Sugar as a product needs to be maintained by Sugar Labs, but that Sugar Labs shouldn't try to constrain the educational approaches used by schools.
Shenki asked how OLPC and RedHat fit in. OLPC (and other platform providers) are downstream and should be pushing patches up to Sugar Labs, making their needs and point of view known to the community. We (the Sugar community) should strive to make our code work for everyone, not just OLPC, so that there is a broader context for support.
It was suggested that we set up a page in the wiki to let people advertise engineering and support services.
===Sugar distributions: what are the issues?===
The bulk of the discussion revolved around what are the best forms of distribution to facilitate people trying Sugar (and if they like it, installing it). We discussed targeting old Windows computers that might be in a school, for example—a version that teachers and students can use.
Carlo suggested that we make a matrix that explains more clearly what you get/don't get from different distribution models, such as a LiveCD, QEMU, etc. It was suggested that distributing Sugar on a USB image is perhaps the best option, since it lets you install additional activities, save files, etc.
Another topic was the need for better documentation: for example, the Sugar session on Ubuntu: Lot of undocumented little details, such as you cannot log out, so you need to either restart X (Ctrl-Alt-Backspace) or do a reboot (from the shell or the Homepage menu); and that you can copy activities directly into ~/Activities. The FLOSS Manuals project has offered to help with documentation; we are considering using the existing Trac system for documentation requests, bug reports, etc.
===Sugar Labs look and feel: a graphic design review===
Luca Ferrari and Franco Lodato presented some designs for a “corporate identity” for Sugar Labs. The designs will be posted in the wiki for feedback. (Karen pointed out the importance of trademarks with in the context of FOSS projects.)
===Sugar on mobile phones: is it possible? does it make sense?===
We also had a discussion about mobile devices. This is a topic that has been raised repeatedly in recent months and, while it doesn't seem to have a direct connection to Sugar's educational goals, it does seemingly broaden the developer community for Sugar (“growing the community”) and bring more people into the circle of collaboration with learners using Sugar-enabled devices.
Further, Sugar would probably make a pretty decent phone interface, especially in light of its clarity of design and its collaborative model.
Still, it was argued that a cellphone screen is a bad environment for learning and that it would not be a substitute for a laptop. Chris Ball asked, “What are the minimum requirements for expressiveness and learning when we work on a port of Sugar?”
We had some discussions about what would be involved in such a port and whom might be interested in doing it. (The Nokia 8000 was suggested as a possible point of departure.)
===Sugar Labs: models of support===
This was in part a continuation of the discussion about purpose. The issue of long-term stability—both perception and reality were discussed: up-take of Sugar will be increased if there is a sense that it is going to be here and supported for the long run. It was argued that we need to help establish local and regional champions, ownership, and support.
:In “biologically inspired” architectures one is much more interested in how the organism and ecologies of them are to be sustained, and how the dynamical systems can be understood, fixed, changed, evolved, reformulated, etc., while they are running and with the help of tools that work within them. Just as a cell, and especially e. g. a human baby, is not made by hand, we are more interested in making growth processes that can be influenced with far more ease than direct construction. So, most objects are made by other objects acting under conditions that include the dynamic state in which they will become part of the ecology. —Alan Kay
What are the Sugar growth processes?
===Fund-raising: how much and from whom?===
We didn't really get into this topic in any detail accept to agree that order 10s of thousands of dollars would probably be adequate for currently anticipated needs: meeting support, outreach, etc.
We do need to discuss what venues would be useful in light of reaching both the developer and user (primarily learning) communities.