> Isn't this related to Brainstorm and Blueprints in Launchpad? Yes, I agree they are closely related.
I would like to take a step back and look at the problems we are trying to solve. Backstory. Over the past couple of months I have spent most of my time working with 'external' people and organizations. I have been looking for ways we can work together. Originally, I though of the problem as how do we Identify, Engage, and Empower potential contributors. That is pretty standard volunteer recruitment strategy. This approach has been creating a dissonance that I did not understand until Mel chewed me out last night. The dissonance is that identifying, engaging, and empowering potential contributors flies in the face of nearly everything Sugar Labs stands for. The correct approach is to focus on creating a community culture where potential contributors can discover what they want to do, discover how to engage with the community, and discover how they can implement their ideas. Identify, Engage, and Empower still holds true. Sugar Labs must be discoverable so new contributors can figure out how they fit in. Consistency and clarity of community. In marketing we often talk about the importance of a clear and consistent message. The release cycle is premised around clear and consistent dates for developers to converge and diverge. The way to make Sugar Labs discoverable is to create a clear and consistent community. Creating this consistency does not depend on long weighty legal tomes. In fact, the opposite is true. This consistency comes from clearly sticking to a few guiding principles. Following are three examples of reoccurring situations that happen across the project. #1 A few months ago we were discussing the the pros and cons of updating Sugar via activities.sugarlabs.org. Initially the discussion were heated and rather handwavey. Then the devteam implemented the 'new feature' process. Engaging in the new feature process shifted _all_ of my energy from _proving_ that update is a good idea to creating a viable implementation. The new feature process provided be a very good template for how to proceed if I wanted my feature to be considered for the next release. I filled out the form and hacked together reasonable proof of concept code. One day a core developer, aslroot, pickup the code and rewrote it. A few days later I got a email from Simon asking me to clean up the release notes because it was going to included in .86. The new process guidelines provided me, the inexperienced developer, a way to align my work flow and expectations with the development team. #2 Last Summer we work we several groups of students. Jameson worked with Mel and Leslie Hawthorn on the GSOC project. Fred worked with Prof. Steve Jacobs and I with the RIT co-op students. Our experiences were very different. At RIT we were flying blind. It was the first time: Anyone taught a course combining community service and technology using open source and Sugar. RIT made an exception to allow unpaid co-ops. RIT allow remote co-op. None of us had clear expectations. Communications suffered. GSOC is now in its 5th iteration. They have very good guidelines for how projects can effectually 'identify, engage, and empower' students. Identify - via the project proposal. Engage - via the mentor. Empower - the student is free to explore, collaborate, and reflect within the limits and expectation of the project. #3 Recently the GSOC team brought in $4500. $2000 in travel money and $2500 in general money. The challenge was determining how to spend it. Rather than push this decision up to the oversight board we appointed the GSOC mentors an ad hoc committee who had authority to spend their money as they see fit. The oversight board is in the process of approving this via lazy consensus. By creating a very light weight decision making body of GSOC mentors we pushed the spending authority out to the people with who were highly engaged in the GSOC project. Themes Life cycle guidelines -- The value of life cycle guidelines show up across the project. The new feature process does a very good job of explaining how to take an idea for a new feature through to becoming part of a release. The process makes no judgment on the value of an idea. Instead it aligns expectations of the new developer and the release team. The GSOC guidelines are another variation on life cycle guidelines. It focuses on best practices to help insure that students, mentors, and projects all have matching expectations. Delegating authority -- The oversight board and the ad hoc GSOC spending committee are are both example of delegating authority through lightweight decision making bodies. It took less than ten minutes to set up the committee and get board approval. The decision are being made by those most knowledgeable about the subject. Future action items. Project guidelines -- Project guidelines are just life cycle guidelines for how top level project can fit into Sugar Labs. The specific problem they solve is forcing premature decisions about what is good, bad, and useful. A recent example of this has been the Qt work Tomeu has been doing. Student guidelines -- Student guidelines are just life cycle guidelines for how student can immerse them selves in the community and become effective contributors in a short period of time. Engineering steering committee -- The committee is just a delegation of decision making authority down to the people who understand the technical needs of the project. Hope this helps explain some of the reoccurring situations which I am working through. Over the next couple of weeks, I will go through these issues again. This time presenting them as solutions to reoccurring problems -- rather than list of things we should do. david _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel