[prev in list] [next in list] [prev in thread] [next in thread] 

List:       helix-open-discuss
Subject:    RE: [Open-discuss] First (real) draft of the roadmap planning doc
From:       Rob Lanphier <robla () real ! com>
Date:       2005-04-29 1:30:19
Message-ID: 1114738219.4515.112.camel () localhost ! localdomain
[Download RAW message or body]

Hi Kevin,

I guess I'm going to have to take advantage of my physical proximity to
get the feedback from the rest of the team, but here's my two cents.

In reading your mail, I realized that we have three uses for the word
"project".  "Project" could mean "Helix Client", or it could mean
"datatype", or it could mean "Cayenne", and your email takes on a
completely different meaning based on that.

So, before getting to the meat of your mail, I'd like to establish some
definitions that I'll try to use consistently throughout (may be hard,
because I didn't compose this linearly).

Area:  Generally one of "Helix Client", "Helix Server", "Helix
Producer", "Helix Player", "Community Ops".  These are the "divisions"
of Helix.

Project: A "project" as defined by the GForge site software, with a
webpage, a set of mailing lists, and other goodies.  I hate reserving
the word "project" for this definition, but I worry that trying to fight
the GForge standard definitions while still using GForge will just end
in tears.  Attempting to extract the word "project" from the GForge
software would be a major, possibly fruitless, undertaking.  Here is a
list of the public projects on helixcommunity.org: 
https://helixcommunity.org/search/?t=allpublic

Plan:  An effort with a scheduled begin date, end date, feature set and
milestones.  Haydon and I brainstormed on this a little bit, and also
came up with "Cycle" or "Effort" to refer to this, but I'll use "Plan"
for now.  Sometimes you hear this referred to as "branch", but that's a
little too overloaded as well, since, for example, we've got a few
subbranches off of the main cayenne_1_5_0 branch.

I'll also use "Plan" instead of "plan" so that you know I'm referring to
these definitions.

We may want to adopt these in the composition of the roadmap docs, but
I'll hold off on that.

More inline.

On Wed, 2005-04-27 at 16:34 -0500, Kevin.Scott@nokia.com wrote:
> Much of the text provided is actually more relevant to a project
> framework than a roadmap framework.  Arguably, it's reasonable to
> enumerate the phases since they are referenced elsewhere in this
> document.  So the guts of this are really the "accomodating feature
> requests and proposals."

I'm guessing here, you mean "Plan framework" by my definitions above.

I'm not sure what you mean by a "roadmap framework".  I would assume
that a useful roadmap would be the listing of active and future Plans,
defined in some sort of standard nomenclature, so that everyone has a
clear sense of what's going on now and can project what will be
happening beyond that.

Is it that you're looking for a way to suggest and/or bargain for new
Plans, in addition to being able to suggest and/or bargain for new
features?  Regardless of whether or not that's what you're asking for, I
think it's something we should probably address.

AI: define way to suggest/bargain for new Plans, in addition to new
features and modifications to existing Plans.

> 1. I'd like to see more info about the accept/reject process.  Who are
> the decision makers?  When and how do decisions get made?

Mysterious smoke-filled rooms at RealNetworks, which surprises me,
because I don't think we allow smoking in the building.  ;-)

I'm only half-kidding...we know this process needs to mature.

Here's my attempt at winging it.  Don't take this as the way things are,
just my take on what a reasonable direction is:
*  Each of the five Areas has a roadmap, and lists the owners for that
Area.  They list the Plans under that Area, and the process for
approving new Plans within that Area.  We may be able to standardize
this, but we'll start by at least getting folks to document the decision
process.
*  Each Plan also has owners, and there's a documented decision making
process there.  Once again, we may standardize, we may not have that
luxury.

> 2. I like the "put your money where your mouth is" categories.

Great!  That's a really important element of all of this.

> 3. How are releases scheduled?

That's going to depend on which Area we're talking about, and probably
even which Plan.

> 4. As a process, this should be clearer about how things get done.
> For example, #1 above...and change from "recommend using bug tracker"
> to "use bug tracker" and give some direction about how to stuff the
> salient info into the tracker.

This is where I really need feedback from others, especially the Area
leaders.

>   If bugzilla is used, some kind of simplified interface would be
> helpful.  It's too confusing to use this URL when all I want to say is
> "we want to see teleporting implemented in Helix, and we're willing to
> pony up 10 developers + 4 testers":
> 
> 	https://bugs.helixcommunity.org/enter_bug.cgi

This is where I can speak with a little more authority.  We're in "Phase
IV - Coding" in the 2005M1 Plan for Community Ops, so any sort of
simplification would probably need to wait for 2005M2.  That assumes
that we get some concrete examples of what would need to change.

Having used it for the 2005M1 Plan, I know it's not perfect, but I think
it's good enough.  Do you have an alternate suggestion?

> 5. I like the Philosophy and Guidelines.

Cool.

> 6. How can "plans be influenced through participation"?

I think that is somewhat addressed in my response on #1 above.  More
directly, contribution leads to influence.  It'll be hard for Area
managers to say "no" to key contributors who we've come to rely on for
really advancing Helix.

So, here's the changes I'll try to address in future iterations:
*  Lock down on vocabulary ("Area", "Project", "Plan").  I'm not in love
with this terminology, but I can live with it.  Speak now if you've got
other suggestions (though please make it clear whether you approve or
disapprove of the term you are looking to replace)
*  Define way to suggest/bargain for new Plans, in addition to new
features and modifications to existing Plans.
*  Define Area and Plan ownership, per #1 above.

Rob

> -----Original Message-----
> From: open-discuss-bounces@helixcommunity.org
> [mailto:open-discuss-bounces@helixcommunity.org]On Behalf Of ext Rob
> Lanphier
> Sent: Friday, April 22, 2005 6:49 PM
> To: open-discuss@helixcommunity.org
> Subject: [Open-discuss] First (real) draft of the roadmap planning doc
> 
> 
> Hi folks,
> 
> Per our various discussions regarding roadmap planning, I've laid out a
> first draft of the document:
> https://community.helixcommunity.org/2005/roadmap/planning
> 
> I had the good fortune of remembering a planning offsite the client team
> had several years ago, and more importantly, where we stashed the
> notes.  ;-)  Thus, much of this document was violently plagiarized from
> the notes from back then, though I've adapted it to our needs here.
> 
> I hope this is a good starting point for a conversation on this matter.
> 
> Rob
-- 
Rob Lanphier, Development Support Manager - RealNetworks
Helix Community: http://helixcommunity.org 
Development Support:
http://www.realnetworks.com/products/support/devsupport



[prev in list] [next in list] [prev in thread] [next in thread]