Talk:Open development/Maemo roadmap
m (Talk:Task:maemo roadmap moved to Talk:Task:Maemo roadmap: Uppercasing Maemo) |
|||
(3 intermediate revisions not shown) | |||
Line 1: | Line 1: | ||
+ | == Roadmap examples == | ||
+ | |||
+ | Some links. Please add yours. Still haven't distilled whether they are good practices or not.--[[User:qgil|qgil]] 06:11, 30 July 2008 (UTC) | ||
+ | |||
+ | * http://www.moblin.org/community/ivi/community_roadmap.php | ||
+ | * http://wiki.openmoko.org/wiki/Roadmap | ||
+ | * http://live.gnome.org/RoadMap | ||
+ | * http://techbase.kde.org/Schedules/KDE4/4.0_Release_Roadmap | ||
+ | * http://www.eclipse.org/org/councils/roadmap_v3_0/index.php | ||
+ | * http://phonon.kde.org/cms/1007 | ||
+ | * Perhaps also worth looking at http://people.freedesktop.org/~jg/roadmap.html | ||
+ | * http://development.openoffice.org/releases/ | ||
+ | * I'm sure you're well-away of this one, but: http://opensource.nokia.com/ (It's interesting that Maemo is not in the Projects list.) --[[User:timsamoff|timsamoff]] 12:41, 30 July 2008 (UTC) | ||
+ | : Yeah, I know about that and in fact is in my ToDo list. Will attack that once the new Maemo is well defined after the 100 Days. However, afaik there are no roadmaps there. Or where? --[[User:qgil|qgil]] 19:32, 30 July 2008 (UTC) | ||
+ | :: Sorry. Saw the one for [http://sofia-sip.org/repos/sofia-sip/TODO Sofia-SIP] and thought each product would have a roadmap. Nope. --[[User:timsamoff|timsamoff]] 20:10, 6 August 2008 (UTC) | ||
+ | |||
+ | ==Dave's feedback== | ||
+ | * I wrote a paper on this for Wengo, a former employer - I could translate it & post it publicly somewhere if there were interest --[[User:dneary|Dave Neary]] 16:21, 6 August 2008 (UTC) | ||
+ | :What about starting publishing the original in French. For me is enough now.--[[User:qgil|qgil]] 19:58, 6 August 2008 (UTC) | ||
+ | * My favourite free software roadmap is [http://wiki.inkscape.org/wiki/index.php/Roadmap Inkscape's] - they have this concept of laying out big plans which will be the guiding principles of a release early, and as they get closer to the release, those guiding principles get broken down and enumerated, people take on features, and they end up with very fine-grained lists of things accomplished in past releases. | ||
+ | :Inkscape is indeed a very good example. I like the way they connect roadmaps (future) with release notes (past). However, Inkscape is just one application and Maemo is a whole platform. Single products/components in this platform could work on roadmaps having references like Inkscape. However, how to apply the good lessons to a Maemo platform roadmap?--[[User:qgil|qgil]] 19:58, 6 August 2008 (UTC) | ||
+ | * Other than that, I have looked - the canonical reference [http://producingoss.org Producing Open Source Software] doesn't say anything about guiding the technical direction of a project. | ||
+ | |||
+ | == Nore comments == | ||
Get a clear public roadmap of what the plans are for the maemo platform for Fremantle. (Note: this doesn't mean a roadmap for ITOS20XX or disclosing new hardware features etc.) --[[User:xfade|xfade]] 12:57, 4 June 2008 (UTC) | Get a clear public roadmap of what the plans are for the maemo platform for Fremantle. (Note: this doesn't mean a roadmap for ITOS20XX or disclosing new hardware features etc.) --[[User:xfade|xfade]] 12:57, 4 June 2008 (UTC) | ||
Give developers a clear list of what library versions are targetted for Fremantle. E.g. glib, gtk+, hildon. --[[User:xfade|xfade]] 12:57, 4 June 2008 (UTC) | Give developers a clear list of what library versions are targetted for Fremantle. E.g. glib, gtk+, hildon. --[[User:xfade|xfade]] 12:57, 4 June 2008 (UTC) | ||
Line 4: | Line 28: | ||
:: There's another thing - some libraries you can't release, without giving up the new hardware specs, what about them? Not released? [[User:bundyo|bundyo]] 21:38, 4 June 2008 (UTC) | :: There's another thing - some libraries you can't release, without giving up the new hardware specs, what about them? Not released? [[User:bundyo|bundyo]] 21:38, 4 June 2008 (UTC) | ||
:::Sure, Nokia won't have to say "we release Diablo on June 5th 2008". But they can say: we plan to use glib 2.12 for Diablo? So at least developers can work towards their own target and know what features to use of the already known libs. This is about common libraries we are already using in the platform, not new ones for new features. --[[User:xfade|xfade]] 07:13, 5 June 2008 (UTC) | :::Sure, Nokia won't have to say "we release Diablo on June 5th 2008". But they can say: we plan to use glib 2.12 for Diablo? So at least developers can work towards their own target and know what features to use of the already known libs. This is about common libraries we are already using in the platform, not new ones for new features. --[[User:xfade|xfade]] 07:13, 5 June 2008 (UTC) | ||
+ | ::::I see this has not been touched in a while so I will. ; ) Users will always want product leaks and such. But we can take that off the table; that's well understood. Things start getting grey as we move toward libraries and such as xfade mentions. So why can't a vague, high-level map be produced? We know this would easily be the case in 100% FOSS projects. So IMO instead of forcing the dialog always toward the "Nokia can't do this" end of the pool, why don't we start with what CAN be released?. --[[User:Texrat|Texrat]] 12:063, 29 Auguest 2009 (UTC) |
Latest revision as of 07:33, 2 November 2009
[edit] Roadmap examples
Some links. Please add yours. Still haven't distilled whether they are good practices or not.--qgil 06:11, 30 July 2008 (UTC)
- http://www.moblin.org/community/ivi/community_roadmap.php
- http://wiki.openmoko.org/wiki/Roadmap
- http://live.gnome.org/RoadMap
- http://techbase.kde.org/Schedules/KDE4/4.0_Release_Roadmap
- http://www.eclipse.org/org/councils/roadmap_v3_0/index.php
- http://phonon.kde.org/cms/1007
- Perhaps also worth looking at http://people.freedesktop.org/~jg/roadmap.html
- http://development.openoffice.org/releases/
- I'm sure you're well-away of this one, but: http://opensource.nokia.com/ (It's interesting that Maemo is not in the Projects list.) --timsamoff 12:41, 30 July 2008 (UTC)
- Yeah, I know about that and in fact is in my ToDo list. Will attack that once the new Maemo is well defined after the 100 Days. However, afaik there are no roadmaps there. Or where? --qgil 19:32, 30 July 2008 (UTC)
[edit] Dave's feedback
- I wrote a paper on this for Wengo, a former employer - I could translate it & post it publicly somewhere if there were interest --Dave Neary 16:21, 6 August 2008 (UTC)
- What about starting publishing the original in French. For me is enough now.--qgil 19:58, 6 August 2008 (UTC)
- My favourite free software roadmap is Inkscape's - they have this concept of laying out big plans which will be the guiding principles of a release early, and as they get closer to the release, those guiding principles get broken down and enumerated, people take on features, and they end up with very fine-grained lists of things accomplished in past releases.
- Inkscape is indeed a very good example. I like the way they connect roadmaps (future) with release notes (past). However, Inkscape is just one application and Maemo is a whole platform. Single products/components in this platform could work on roadmaps having references like Inkscape. However, how to apply the good lessons to a Maemo platform roadmap?--qgil 19:58, 6 August 2008 (UTC)
- Other than that, I have looked - the canonical reference Producing Open Source Software doesn't say anything about guiding the technical direction of a project.
[edit] Nore comments
Get a clear public roadmap of what the plans are for the maemo platform for Fremantle. (Note: this doesn't mean a roadmap for ITOS20XX or disclosing new hardware features etc.) --xfade 12:57, 4 June 2008 (UTC) Give developers a clear list of what library versions are targetted for Fremantle. E.g. glib, gtk+, hildon. --xfade 12:57, 4 June 2008 (UTC)
- Ok to the idea but as for today we cannot commit publicly to a specific date, nor guarantee that this will be done within 100 days. It won't be 2010 either, most probably at some point during the second half of this year. What should we do? Add it with a disclaimer? Leave it out? --qgil 20:21, 4 June 2008 (UTC)
- There's another thing - some libraries you can't release, without giving up the new hardware specs, what about them? Not released? bundyo 21:38, 4 June 2008 (UTC)
- Sure, Nokia won't have to say "we release Diablo on June 5th 2008". But they can say: we plan to use glib 2.12 for Diablo? So at least developers can work towards their own target and know what features to use of the already known libs. This is about common libraries we are already using in the platform, not new ones for new features. --xfade 07:13, 5 June 2008 (UTC)
- I see this has not been touched in a while so I will. ; ) Users will always want product leaks and such. But we can take that off the table; that's well understood. Things start getting grey as we move toward libraries and such as xfade mentions. So why can't a vague, high-level map be produced? We know this would easily be the case in 100% FOSS projects. So IMO instead of forcing the dialog always toward the "Nokia can't do this" end of the pool, why don't we start with what CAN be released?. --Texrat 12:063, 29 Auguest 2009 (UTC)
- Sure, Nokia won't have to say "we release Diablo on June 5th 2008". But they can say: we plan to use glib 2.12 for Diablo? So at least developers can work towards their own target and know what features to use of the already known libs. This is about common libraries we are already using in the platform, not new ones for new features. --xfade 07:13, 5 June 2008 (UTC)
- There's another thing - some libraries you can't release, without giving up the new hardware specs, what about them? Not released? bundyo 21:38, 4 June 2008 (UTC)
- This page was last modified on 2 November 2009, at 07:33.
- This page has been accessed 11,784 times.