Hi, (Sorry for the poor formatting - Gmail on BlackBerry doesn't seem to support manual quoting...)
Firstly, this would probably be best on the forum - or meego-community at a push - as this is where the conference is being planned. Your proposal sounds interesting for a "Developing MeeGo" track - but remember the conference is much more than that: * Hobbyist community developers * Power users and enthusiasts * Bloggers/journalists * Commercial developers * and, apparently, OEMs and vendors. A mix of styles is going to be necessary. Think of the big tech conferences (like JavaOne) or even a sci-fi con: the hardcore kernel hackers who turn up dressed as Klingons, the toolkit devs who turn up as tribbles and then the avid watcher who just wants to soak up some atmosphere, chat to fellow geeks and get some autographs. Cheers, Andrew On 29/05/2010, Sivan Greenberg <[email protected]> wrote: > Hi All, > > 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. > > 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]. > > 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. > > 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. > > Sivan > ------- > [0]: http://wiki.meego.com/MeeGo_Conference_2010#Format > [1]: https://wiki.ubuntu.com/HomeUserBackup > _______________________________________________ > MeeGo-dev mailing list > [email protected] > http://lists.meego.com/listinfo/meego-dev > -- Andrew Flegg -- mailto:[email protected] | http://www.bleb.org/ Maemo Community Council chair _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
