A few observations:<div><br></div><div>1) I'm new to VLC but not to project management with volunteers. Shelley's points are well taken.</div><div>2) To Karlo's point about "Bad/fake/broken promises are the cancer of software industry" -- I totally agree when those promises are made as marketing tools, that is, to users or potential users. A roadmap is no such thing -- it is an *internal* guideline -- in essence, a promise (more of a goal-setting) to *each other*.</div>
<div>3) We already have a roadmap. The very statement that a "feature freeze" is proposed for May 31 means that, if agreed, the roadmap has a feature freeze of May 31. That's rudimentary, but on the right track. A better roadmap might be:</div>
<div>--Today through Feb. 15: brainstorm new feature ideas (like Shelley's on bookmarks) for what would be 3.0 in my proposed numbering scheme. (Face to face meetings are helpful for this, I find.)  No ideas are discarded during this phase, even if wild, ridiculous or harmful to VLC.</div>
<div>--March 31: core team members finish prioritizing features they feel are important and divvy up the ones they are willing to commit to working on. Others are placed in the "projects for outside volunteers" bin.</div>
<div>--April 1 to May 31: additions to feature list considered and triaged as they come up. None are written off unless considered harmful to VLC. Less important ones, or ones the core members don't want to tackle, go into the "projects for outside volunteers" bin. No further features are considered for this release; they go into 4.0. (At this point, a 4.0 branch can be opened.)</div>
<div>--Sept. 30: Target for first pre-release, version 3.0.x. Features that have nobody working on them are reassigned to 4.0.</div><div>--Dec. 31: Target for public release. (3.1.0 in my proposed numbering scheme.)</div>
<div><br></div><div>I'm fairly sure Shelley has something like this in mind. Milestones and their dates can be debated, but I think a roadmap, or outline, is useful. As I noted, JB and Remi are already debating one aspect of a roadmap. To Karlo's point, nobody is penalized for missing the deadline; the feature simply misses the 3.1 release and can always be added to 3.2 (development), 3.3 (release) or 4.0 when ready. Also to Karlo's point about fixing release-blocker bugs: failure to fix them would delay the target dates, of course, but that's why they're targets.</div>
<div><br></div><div>In any case, this is all theory based on what has worked for non-VLC projects. I see that Christophe Mutricy has some real-world VLC project management experience and wonder what his views are.</div><div>
<br></div><div><br></div><div><div class="gmail_quote">On Mon, Jan 9, 2012 at 6:52 AM,  <span dir="ltr"><<a href="mailto:vlc-devel-request@videolan.org">vlc-devel-request@videolan.org</a>></span> wrote:<br><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
From: Shelley Horwitz <<a href="mailto:shelley@sjcomm.com">shelley@sjcomm.com</a>>:<br><br>
I have not seen any comments about my 3 requests:<br>
<br>
1. To have bookmarks saved in a file so I may reuse them on subsequent viewings of video and movies.<br>
2. To be able to name the bookmarks (like bookmarks in my browser).<br>
3. To have a bookmark button in the controls so I don't have to go to the menu.<br>
<br>
Any comments or opinions about the desirability of these features or priority for having them?<br>
<br>
Shelley<br>
<br>From: Shelley Horwitz <<a href="mailto:shelley@sjcomm.com">shelley@sjcomm.com</a>>:<br>
</blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Kaarlo,<br>
<br>
I will try to remember to switch to plain text for all my messages. Thank you for the reminder.<br>
<br>
Now... to our discussion. I do not want to make this a personal debate.... only to make VLC a better product in the world of players.<br>
<br>
Even in volunteer organizations, and I have worked in several (Boy Scouts, Girl Scouts, for example), most people react well to goals, targets, and schedules. Actually, I believe the majority of people working on projects in volunteer organizations appreciate and work better in a scheduled environment. The schedule is NOT a threat, but a guide that helps them shape their work and pleasure hours to get the most out of their contributing energies. In my experience, a lot of people do not focus their minds and activities when they have no clear idea of when something is due. Because there is no "time-limit," there is no focus on performing a task. Because there is no time limit, there is no need to work today... there is all the time in the world to do it tomorrow. Everybody procrastinates when there is no well-defined finish line in sight. People don't procrastinate when they have a goal and a timeline... either given to them or they set it themselves.<br>

<br>
[snip]<br>
</blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Date: Sun, 8 Jan 2012 14:29:45 +0200<br>
From: Kaarlo R?ih? <<a href="mailto:kaarlo.raiha@gmail.com">kaarlo.raiha@gmail.com</a>><br>
</blockquote><div>  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[snip]<br>
And you are completely missing the point of volunteer vs. paid developers.<br>
Since most people related to VLC development do this as a hobby, it isn't<br>
feasible to make them work with any schedules or force them to do certain<br>
features. Even current releases are stressful events because only few<br>
people do release blocker bug fixing, and if someone would be forced to do<br>
that, I think they would quit pretty fast.<br>
<br>
IMHO roadmaps aren't useful if there isn't any guarantee for events in it<br>
to happen. Bad/fake/broken promises are the cancer of software industry.<br>
<br></blockquote></div></div>