Home » General (non-technical) » Eclipse Foundation » [EDP] Roadmap Process
| [EDP] Roadmap Process [message #40910] |
Mon, 30 October 2006 19:07 |
 Bjorn Freeman-Benson
Messages: 334
Registered: July 2009 |
Senior Member |
|
|
(Note: I have moved this conversation from the wiki page to this
newsgroup because the newsgroup seemed like a better place to have a
back-and-forth conversation. A summary of, and pointer to, this
conversation is on the wiki page.)
Bjorn Freeman-Benson writes:
> The Roadmap Process continues to be a point of contention
> amongst projects and members. I think it would be best to adopt
> a description that everyone can accept and follow; it does not
> help our community to have a documented Roadmap Process that we
> do not actually follow. For example, what are the consequences
> should a Project choose to change direction mid-year and not
> implement features that were in the original Project Plan? In a
> strict reading of the above section, that action would put
> the approved Roadmap in jeopardy - would we actually prevent
> the Project from doing that work?
Scott Lewis writes:
> Would it help to use the individual project plans as more of
> the basis of the Roadmap construction effort? Maybe extract
> themes and priorities from these plans...along with
> identifying cross-project dependencies...as the primary
> method for Roadmap construction and iterative modification.
> Perhaps not -- maybe this is already what is happening in the
> Roadmap development
Anurag Gupta writes:
> Input from top level projects is one of the inputs that is
> currently used in determining themes and priorities. Other inputs
> are from strategic member companies, add-provider companies,
> and market research / analyst discussions. Identifying
> cross-project dependencies mostly happens 1:1 between two projects
> and sometimes via the Architecture Council and / or Planning
> Council if multiple projects are involved.
Dave Bernstein writes:
> A Roadmap Process that everyone accepts and follows but is
> completely ineffective won't help the Eclipse Community either.
> No Roadmap Process can eliminate contention; contention is a
> given. The objective is a Roadmap Process that
> appropropriately balances the often conflicting goals of
> moving Eclipse forward, and moving individual Projects forward.
Tim Wagner writes:
> Defining a roadmap for Eclipse-as-a-whole has the potential to
> make the roadmap little more than apple pieisms. I'd advocate
> more of a project-targeted focus, where the requirement council
> works individually with each top-level project in turn to refine
> their individual plans rather than a single uber document. This
> would force attention to specifics and concrete items rather
> than "be a great platform" or "be cool" goals that provide
> little in the way of specifics when a project formulates
> its plan. There are a few horizontal/cross-cutting concerns,
> but they should be born out in specifics on a per-project basis.
Dave Bernstein writes:
> I agree that "be a great platform" or "be cool" goals
> aren't meaningful drivers for an Eclipse Roadmap, but that's
> no reason to forgo broad initiatives that require concerted
> effort among the Projects. Otherwise, Eclipse will devolve to
> a bag of independent efforts.
Rich Main writes:
> Speaking as one who originally lobbied for the creation of
> the Requirements Council, I have to point out here that the
> purpose is to allow the broader community to help define
> the requirements. This input should even come from "outside"
> sources like NASA, JP Morgan, Cisco, and others who are
> key users but not foundation members. Add-in Provider members
> can also act as proxies for gathering requirements from
> valuable target markets.
> Such input is the lifeblood of innovation and critical to
> the ongoing success of Eclipse. If we simply allow the
> individual project plans to guide the roadmap process,
> then Eclipse loses this valuable and strategic
> requirements input.
Rich Main writes again:
> For reference, I added a link above to the
> http://www.eclipse.org/org/councils/roadmap_v2_0/index.php#p rocess
roadmap process
> I would like to understand specifically which part of
> the defined roadmap process is "a point of contention". It's
> hard to suggest fixes for something if you don't understand
> where people think that it's broken. But, I have to echo
> Dave's comment that contention is a given. There is a necessary
> give and take in the requirements and planning process. The
> current roadmap process is intentionally designed such that
> the direction of Eclipse is guided by more than just the
> sum of the various project vectors. Without the roadmap
> process at all, then who is steering the "good ship Eclipse"?
Bjorn Freeman-Benson writes:
> The contention I was referring to above is between the
> Requirements Council's (RC) desire to provide direction to the
> Projects and the Projects' desire to do their own thing. To
> be blunt, at times the RC has been tempted to "tell the
> Platform to fix bug X" but the Platform team has no
> obligation to do so.
Rich Main writes:
> Bjorn: In principle, I agree with you. Telling a project
> team to fix a specific bug sounds like micro-management
> on the surface. But, it may depend on the bug in question.
> For example (and this is a contrived example because I doubt
> that it actually happened in this case), since support
> for the Mac is an important strategic initiative from
> a requriements standpoint, directing a project to work
> with Apple to fix SWT issues on the Mac would not be
> inappropriate input for the Requirements Council to
> provide, IMO. In fact, it should be viewed as very
> constructive and valuable input to guide the project team
> to devote resources in ways that are meaningful to the
> community at large. This is part of the purpose of
> the Requirements Council and sometimes that may end up
> looking like micro-management when in actuality it is
> reinforcement of the "receptivity" ethic.
Dave Bernstein writes:
> In its enumeration of the EMO's responsibilities,
> section 7.1 of the Eclipse Bylaws includes
>
> "leading the Architecture Council and the Planning Council
> to produce a Roadmap (as defined in the then current
> Eclipse Development Process) that is consistent with the
> Purposes (as defined in Section 1.1 above)"
>
> The Eclipse Development Process defines 4 steps in
> the Roadmap Process:
>
> 1. The Purposes are established in the Bylaws. The
> Membership at Large approves updates to the Purposes.
>
> 2. The EMO proposes an initial Roadmap or Roadmap
> update consistent with the Purposes.
>
> 3. The Board of Directors approves the Roadmap.
>
> 4. With the support of EMO project management, Development
> Teams work to the Roadmap.
>
> The Development Process enumerates the following criteria
> for each Project Plan:
>
> • Conforms to the Architecture Plan
>
> • Consistent with the priorities and themes of the Roadmap
>
> • Accommodates cross-project dependencies
>
> • Addresses requirements critical to the Ecosystem and/or
> the Membership at Large
>
> • Advances the Project in functionality, quality, performance
>
> With respect to Project flexibility and autonomy, the
> Development Process says:
>
> "A Project Lead is expected to work to the Project Plan, and
> ensure that all plans, technical documents and reports are
> publicly available. A Project Lead can incrementally revise
> their Project Plan to deliver additional Tasks provided:
>
> • The approved Roadmap is not put in jeopardy
>
> • The work is consistent with the Project Plan criteria
> (described above)"
>
> None of the above empowers the Requirements Counci to demand
> that some Project correct bug X tomorrow, but the correction
> of a serious defect whose existence jeopardizes the Roadmap
> could reasonably appear in the Council's Themes and Priorities
> during a Roadmap Update.
>
> The suggestion that Projects simply do their own thing is
> entirely inconsistent with the current Bylaws and Development
> Process; had that been the desired model, both documents would
> have been much easier to develop and syndicate! Anyone
> promulating this radical a change should be proposing a new
> set of Bylaws and a new Development Process, not an "update"
> to the existing model.
Scott Lewis writes:
> Dave: I don't see this document as suggesting the radical
> change that you apparently do...i.e. I don't think it says
> that the projects should 'do their own thing'. Rather, it
> seems to be a reasonable adjustment based upon what has (in
> practice) worked, and what hasn't worked. It's hard to tell,
> but it seems as though you have a significantly different
> model in mind for this development process revision than
> what Bjorn has proposed. Do you have another model in mind?
> If so, what is that alternative model? Thanksinadvance for
> clarification.
Dave Bernstein writes:
> Scott, I was responding to the suggestion in this thread that
> the Roadmap be assembled from individual Project plans rather
> than be developed from Eclipse-level themes and priorities.
> It is that suggestion that I characterized as radical, not
> the proposed update.
|
|
|
Goto Forum:
Current Time: Fri Apr 19 14:46:00 GMT 2024
Powered by FUDForum. Page generated in 0.01207 seconds |
] 
Search
Help
Register
Login
Home
