[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[News.eclipse.foundation] Re: [EDP] What is motivating this revision?
Dave wrote:
1. After reviewing the suggested URL, I conclude that "Incubation phase" is a synonym for "Validation phase". If so, I recommend making this explicit in proposed process revision.

In the proposed process revision there is no Validation phase; could you clarify where this should be made explicit? The main difference between the former Validation phase and the new Incubation phase is that the Validation phase was something that occurred for each release and was about validating the technology, and the Incubation phase is something that happens once per project and is mostly about validating the project process and community.

3. The architecture minutes are rather sparse, but it would appear that the good progress made during 2004 was not carried forward. The obvious question is whether the problems are best solved by improving the development process, by better populating and orchestrating the Council, or both.

As you know (because, I believe, you wrote most of the Eclipse Foundation Bylaws), the population of the Architecture Council is mostly predetermined. While the EMO is allowed to add people to the council by appointment, there is no mechanism for removing or replacing people [1]. Hence I don't understand your suggestion to "better populate" the Council? Are you suggesting that we (the EMO, the community) appoint dozens more people to the Council so as to stack the deck?

I'm also a little puzzled about your statement of "good progress during 2004". As far as I can tell from the minutes, in 2004 the Architecture Council:
* Discussed the need for the UI Working Group (not created until just last month and then by the Board, not the AC) [2]
* Discussed the need for an API review process (never happened) [2]
* Watched slideware project overviews (probably box architecture slides) of some of the projects [2]
* Agreed to produce project architecture descriptions [2]
* Reviewed Mike's boxes diagram of the architecture [3]
* Watched more slideware project overviews [3]
* Discussed a top-level Languages PMC (never happened) [3]
* Contributed only Mike's boxes diagram of the architecture to the Roadmap [4]
So the Council met, showed each other architecture box slides, and did not produce the piece of the Roadmap they agreed [2] to produce? How is that considered "good progress"? (Sorry if I sound disappointed here, but perhaps my standards for "good progress" are higher than yours. My standards for good progress include, at a minimum, doing the work that one is chartered to [1,5], and agrees to [2], do.)

[1] http://www.eclipse.org/org/documents/Eclipse%20BYLAWS%202003_11_10%20Final.pdf#page=20
[2] http://www.eclipse.org/org/councils/20040902ACMinutes.pdf
[3] http://www.eclipse.org/org/councils/20041202ACMinutes.pdf
[4] http://www.eclipse.org/org/councils/roadmap_v1_0.html
[5] http://www.eclipse.org/org/documents/Eclipse%20Development%20Process%202003_11_09%20FINAL.pdf#page=3

4. I find nothing in the proposed process revision that would address the "reviews are poorly attended" issue, so its hard to suggest a better alternative. If I'm overlooking something, please point it out.

While we cannot force people to attend meetings (and what an awful world it would be if we could do so!), we added these bits to the proposed process to encourage more participation:

* Reviews are a week long discussion instead of a single 15 minute phone call ("The Review itself: 1. ..." [6])
* Reviews require a successful public vote from more than just the Project members ("5. At the end ... a public vote ..." [6])

[5] http://wiki.eclipse.org/index.php/Development_Process_2006_Revision#Reviews

5. Ensuring the quality of APIs and frameworks across the Eclipse projects is a primary responsibility of the Architecture Council; I can think of no reasonable grounds on which the Architecture Council could pass on this. If this is the basis for your characterizing the Architecture Council as "ineffective", I agree. Ignoring our disagreement over how to structure it, a group of Mentors willing to coach new projects seems like a good idea, but allowing the Architecture Committee to shirk its responsibility for ensuring the quality of APIs and frameworks across Eclipse projects is a very bad idea.

Dave, I am definitely open to any suggestions and ideas about how to make the Architecture Council effective. I (a) think it's a harder problem than you imagine and (b) have already offered my resignation as the chair due to my inability to convince the Council to produce anything (my resignation was rejected by the Council).

I see three main difficulties with the Architecture Council:

1. The Council members have, in spite of my best efforts, never put much/any effort into their responsibility "for providing an explicit
description of the architecture" [5]. While I cannot speak for the individuals, my understanding is that they do not see an architecture description as a useful document.

2. Architectural issues are the larger issues in a software project and, as larger issues, they are not easily solved in a few hours of conversation once every three months. Thus the Council members feel that the Architecture Council is not a useful mechanism for discussing architectural issues. They feel that the correct mechanism is person-to-person discussions between experts on each project: a higher bandwidth and lower latency solution.

3. The Architecture Council has not come up with an architecture-oriented action or plan that the members are willing to (or are given time by their employers to) execute on. Various actions have been proposed but either (3a) lack follow through by the members (probably because their employers do not deem these things important enough to spend time on) or (3b) the Council does not attain consensus on the idea.

If you have suggestions of how we can overcome these difficulties -- to summarize: (i) architectural descriptions are not useful, (ii) architectural problems are too big for infrequent short meetings to resolve, and w(iii) e cannot find a low-effort architectural task to take on -- please feel free to let the Council know about it.

Regards,
Bjorn