On Fri, 28 May 2010 18:55:02 -0600, Sivan Greenberg <[email protected]> wrote: > > Going over the format section in [0] I feel that so far the suggested > approaches are more for a presentation event, or an expo and is less > facilitating concrete brainstorming with documented results.
The current plan is to have two days of a more traditional, presentation focused conference and one day of a (for lack of a better word) unconference. That third day might be more what you are looking for. > I would like to propose that we follow the following format, and I > volunteer to help the process and drive it if there are no other takes > already. > > So, an idea, feature or workflow proposal should be written as a > specification. People do write ups of their suggestions in the form of > wiki specs. A spec wiki page has a certain format that makes it easy > after wards to carry the implementation, further discuss it or > refactor an already existing feature or a piece of software. > Incidentally the spec also serves as the first line of documentation > and an excellent starting point for people looking to apply a new > feature or functionality and/or to test it. > > To get an idea how such a wiki spec page looks, read through [1]. I'm always a bit confused about the relationship between proposals like this and the actual implementation work - in your example, who would commit to actually implementing the feature or workflow suggested? > A review board is to be formed, which will review each spec written > during the conference and approve it not in terms of relevance to the > project or time frame but in terms of completeness and quality of the > spec. The idea is that anyone of the developer team, including those > who did not attend the sprint will be able to carry the > implementation. So the proposal is made by "the developer team", i.e. the people who commit to then implement this feature in time for the next code freeze? > The drivers board will after the event or after submission of all > specs is done, choose the specs that they think is most relevant to > the upcoming release, and that can be completed in a proper manner > (including QA). The drivers board should be assisted by the spec > author to consult about ETAs of the specific functionality or feature. > > The end result of this that we finish the summit with a well defined > agenda for the next release and with concrete and agreed set of > features, bug fixes and functionality that is more predictable and > easy to follow and expect, even from the the point of view of users in > addition to the developers. So in your vision the MeeGo Conference would be where all the features for the next version of MeeGo are decided? Given that we are currently targeting two releases a year but just one conference a year... that seems mismatched. I also wonder if this process is actually the best use of time for the conference, but I'm open to discussion here. /D -- Dirk Hohndel Intel Open Source Technology Center _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
