[News.eclipse.foundation] Re: [EDP] What is motivating this revision?

["Dave" <dave.bernstein@xxxxxxxxxxx>]

+++ my comments below

    Dave

"Bjorn Freeman-Benson" <bjorn.freeman-benson@xxxxxxxxxxx> wrote in message 
news:45462BE2.9040006@xxxxxxxxxxxxxx

> 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.

+++OK, I see the "diagram" now.

+++In the current development process, the validation phase culminates in a 
checkpoint review that confirms that the Project has a plan to achieve its 
objectives, verifies that all intellectual property rights issues have been 
resolved, and ensures the Project is consistent with the expectations 
established in the Project Proposal. This checkpoint review provides a 
further opportunity for Members to identify any intellectual property they 
may have that may be infringed/misappropriated by the Project without a 
license to that intellectual property. In the proposed process revision, 
when would these checks be performed?

+++While the revision describes the proposed phases, it says little about 
the function and content of the proposed creation review, incubation review, 
promotion review, release review, or termination review.


>> 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 did not write any of the Foundation Bylaws. I led the effort to develop 
the governance model and development process, which incorporated 
contributions from many Eclipse Consortium members, as well as from a few 
people outside Eclipse. Mike Rank's Legal Committee wrote the Bylaws.

+++ Adding people is certainly one way of better populating the council. 
"Stacking the deck", as you call it, would not be my preferred solution --  
but if it were the only way to achieve a functional Architecture Council, 
I'd do it in a heartbeat before allowing Eclipse to fail.

+++ If a member of the Architecture Council is not fulfilling his or her 
responsibilities, then I would expect the EMO to engage with that member's 
Board representative to correct the situation by arranging for more of the 
members time to be available, by coaching the member, or if necessary by 
replacing the member.


> 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.)

+++From the minutes, it appeared that the Architecture Council was actively 
focused on the right things during 2004. If, as you say, the Council failed 
to follow through, then clearly momentum was lost.


>> 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])

+++ Those might help. Did you query individual members to determine why they 
weren't participating in reviews? If so, what did you learn?


>> 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.

+++ Your comments, which included the coined word "frameworkness", seem to 
have dissappeared from the Wiki without being relocated to this newsgroup, 
but my understanding is that both the Board and Requirements Council asked 
the Architecture Council to take responsibility for ensuring the development 
of high-quality frameworks and interfaces. This absolutely requires an 
explicit description of the architecture -- not just for the Architecture 
Council's use, but for syndication to all Projects.

+++ I see nothing in the Bylaws or Development Process that limits the 
Architecture Council to a few hours of conversation once every three months. 
The Architecture Council is free to organize its work as it deems necessary 
to satisfy its responsibilities.

+++ The impression you give is that the current members of the Architecture 
simply lack the time and energy required to satisfy their responsibilities. 
If that's true, then as discussed earlier, the EMO should add sufficient 
resources to achieve critical mass, engage with Board members to obtain 
additional time from Architecture Council members, or both.

     Dave