Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » General (non-technical) » Eclipse Foundation » [EDP] What is motivating this revision?
[EDP] What is motivating this revision? [message #40682] Fri, 27 October 2006 20:25 Go to next message
Bjorn Freeman-Benson is currently offline Bjorn Freeman-Benson
Messages: 335
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.)

>>>> Dave Bernstein writes:
>>>> Is there a summary of the issues motivating this revision?
>>>> If so, please provide a URL. If not, this would seem like
>>>> a good first step.
>>>
>>> Dave Berstein writes:
>>>
http://eclipse-projects.blogspot.com/2006/09/your-comments-o n-eclipse-development.html
>>> says
>>> "The goal of this revision is update the process-as-written
>>> to match the process-as-practiced. We've also added a new
>>> section about mentorship and a requirement that projects get
>>> a public review at least annually."
>>>
>>> Two questions:
>>> * What are the significant differences between the
>>> process-as-written and the process-as-practiced?
>>> * Is the process-as-practiced in all respects superior to
>>> the process-as-written?
>>
>> Bjorn Freeman-Benson writes:
>> I cannot speak for the entire community, but some of the
>> differences which are readily observable by watching the
>> projects include: (i) no Validation phase; yes Incubation phase;
>> (ii) sub-projects with sub-projects; (iii) Architecture Council
>> is ineffective; (iv) Reviews are poorly attended; (v) the level
>> of framework-ness (to coin a phrase) across projects is highly
>> variable; etc. Whether the new process is superior to the old is
>> up to the community to decide - I certainly hope that
>> collectively we improve the process and I appreciate everyone
>> who is taking the time to work towards that end.
>
> Dave Bernstein writes:
> re "(i) no Validation phase; yes Incubation phase" - a
> project's Validation phase could be arbitrarily short, but the
> EMO is responsible for holding a Checkpoint review before the
> Implementation phase begins. Are Checkpoint reviews routinely
> held? How is an Incubation phase different than a Validation
> phase?
>
> re "(ii) sub-projects with sub-projects" - where is this
> addressed in the proposed update?
>
> re "(iii) Architecture Council is ineffective" - I'm
> extremely dissapointed to hear this. In what ways is this
> Council ineffective. What action has the EMO taken, and what
> has been their result? Where in the proposed update is
> this problem addressed?
>
> re "(iv) Reviews are poorly attended" - Have you polled the
> Eclipse community to determine why this is the case? What
> did you learn? Where in the proposed update is this problem
> addressed?
>
> re "(v) the level of framework-ness (to coin a phrase) across
> projects is highly variable; etc." -- If we're going to coin
> phrases, lets coin ones that are explicit and meaningful; I
> have no idea what "framework-ness" means; Can you be more
> explicit? Where in the proposed update is this problem
> addressed?
>
> My impression is that the proposed update addresses few of
> what you cite as the differences between the process-as-written
> and the process-as-practiced, but contains lots of commentary
> on unrelated matters.

(i) Please read these web pages:
http://www.eclipse.org/projects/dev_process/

(ii) That issue and any potential solutions is still under discussion.
See
http://eclipse-projects.blogspot.com/2006/10/edp-structure-a nd-organization-9-of-17.html

(iii) I'm disappointed as well. You are welcome to read the Architecture
Council minutes (http://www.eclipse.org/org/foundation/council.php). In
addition, the EMO has made a number of presentations to the Board on
this issue - you are welcome to contact your Board member for more
details (http://www.eclipse.org/org/foundation/directors.php).

(iv) This issue has also been discussed at length with the Board and the
project leadership. The proposed Development Process revision is the
outcome of those discussions... However, if you have a better idea, I'm
sure that all of us in the community would be happy to consider it.

(v) The mentorship proposal was proposed by the Planning Council and the
Board of Directors to address concerns about quality of APIs,
frameworks, and tools across the Eclipse projects.

- Bjorn
Re: [EDP] What is motivating this revision? [message #40713 is a reply to message #40682] Fri, 27 October 2006 20:31 Go to previous messageGo to next message
Bjorn Freeman-Benson is currently offline Bjorn Freeman-Benson
Messages: 335
Registered: July 2009
Senior Member
Oops, forgot the wiki page URL:
http://wiki.eclipse.org/index.php/Development_Process_2006_R evision

Bjorn Freeman-Benson wrote:
> (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.)
Re: [EDP] What is motivating this revision? [message #40816 is a reply to message #40682] Sat, 28 October 2006 09:50 Go to previous messageGo to next message
Dave Bernstein is currently offline Dave Bernstein
Messages: 8
Registered: July 2009
Junior Member
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.

2. I recommend creating a place-holder in the proposed process revision for
the "sub-projects within sub-projects" issue so that the community knows
that potential solutions are under discussion elsewhere, and can contribute
if desired.

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. The
statement "Someone brought up that the council needs to have an action
focused goal" in the most recent Architecture Council meeting minutes begs
for action, especially in light of #5 below.

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.

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


"Bjorn Freeman-Benson" <bjorn.freeman-benson@eclipse.org> wrote in message
news:ehtpvp$j0a$1@utils.eclipse.org...
> (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.)
>
> >>>> Dave Bernstein writes:
> >>>> Is there a summary of the issues motivating this revision?
> >>>> If so, please provide a URL. If not, this would seem like
> >>>> a good first step.
> >>>
> >>> Dave Berstein writes:
> >>>
> http://eclipse-projects.blogspot.com/2006/09/your-comments-o n-eclipse-development.html
> >>> says
> >>> "The goal of this revision is update the process-as-written
> >>> to match the process-as-practiced. We've also added a new
> >>> section about mentorship and a requirement that projects get
> >>> a public review at least annually."
> >>>
> >>> Two questions:
> >>> * What are the significant differences between the
> >>> process-as-written and the process-as-practiced?
> >>> * Is the process-as-practiced in all respects superior to
> >>> the process-as-written?
> >>
> >> Bjorn Freeman-Benson writes:
> >> I cannot speak for the entire community, but some of the
> >> differences which are readily observable by watching the
> >> projects include: (i) no Validation phase; yes Incubation phase;
> >> (ii) sub-projects with sub-projects; (iii) Architecture Council
> >> is ineffective; (iv) Reviews are poorly attended; (v) the level
> >> of framework-ness (to coin a phrase) across projects is highly
> >> variable; etc. Whether the new process is superior to the old is
> >> up to the community to decide - I certainly hope that
> >> collectively we improve the process and I appreciate everyone
> >> who is taking the time to work towards that end.
> >
> > Dave Bernstein writes:
> > re "(i) no Validation phase; yes Incubation phase" - a
> > project's Validation phase could be arbitrarily short, but the
> > EMO is responsible for holding a Checkpoint review before the
> > Implementation phase begins. Are Checkpoint reviews routinely
> > held? How is an Incubation phase different than a Validation
> > phase?
> >
> > re "(ii) sub-projects with sub-projects" - where is this
> > addressed in the proposed update?
> >
> > re "(iii) Architecture Council is ineffective" - I'm
> > extremely dissapointed to hear this. In what ways is this
> > Council ineffective. What action has the EMO taken, and what
> > has been their result? Where in the proposed update is
> > this problem addressed?
> >
> > re "(iv) Reviews are poorly attended" - Have you polled the
> > Eclipse community to determine why this is the case? What
> > did you learn? Where in the proposed update is this problem
> > addressed?
> >
> > re "(v) the level of framework-ness (to coin a phrase) across
> > projects is highly variable; etc." -- If we're going to coin
> > phrases, lets coin ones that are explicit and meaningful; I
> > have no idea what "framework-ness" means; Can you be more
> > explicit? Where in the proposed update is this problem
> > addressed?
> >
> > My impression is that the proposed update addresses few of
> > what you cite as the differences between the process-as-written
> > and the process-as-practiced, but contains lots of commentary
> > on unrelated matters.
>
> (i) Please read these web pages:
> http://www.eclipse.org/projects/dev_process/
>
> (ii) That issue and any potential solutions is still under discussion. See
> http://eclipse-projects.blogspot.com/2006/10/edp-structure-a nd-organization-9-of-17.html
>
> (iii) I'm disappointed as well. You are welcome to read the Architecture
> Council minutes (http://www.eclipse.org/org/foundation/council.php). In
> addition, the EMO has made a number of presentations to the Board on this
> issue - you are welcome to contact your Board member for more details
> (http://www.eclipse.org/org/foundation/directors.php).
>
> (iv) This issue has also been discussed at length with the Board and the
> project leadership. The proposed Development Process revision is the
> outcome of those discussions... However, if you have a better idea, I'm
> sure that all of us in the community would be happy to consider it.
>
> (v) The mentorship proposal was proposed by the Planning Council and the
> Board of Directors to address concerns about quality of APIs, frameworks,
> and tools across the Eclipse projects.
>
> - Bjorn
Re: [EDP] What is motivating this revision? [message #40847 is a reply to message #40816] Mon, 30 October 2006 16:44 Go to previous messageGo to next message
Bjorn Freeman-Benson is currently offline Bjorn Freeman-Benson
Messages: 335
Registered: July 2009
Senior Member
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%2 0Process%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_R evision#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
Re: [EDP] What is motivating this revision? [message #40943 is a reply to message #40847] Tue, 31 October 2006 06:17 Go to previous messageGo to next message
Dave Bernstein is currently offline Dave Bernstein
Messages: 8
Registered: July 2009
Junior Member
+++ my comments below

Dave

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

> 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
Re: [EDP] What is motivating this revision? [message #41005 is a reply to message #40943] Tue, 31 October 2006 15:58 Go to previous messageGo to next message
Bjorn Freeman-Benson is currently offline Bjorn Freeman-Benson
Messages: 335
Registered: July 2009
Senior Member
Dave wrote:
> +++ Your comments, which included the coined word "frameworkness", seem to
> have dissappeared from the Wiki without being relocated to this newsgroup,

Dave, I'm sorry that you did not take the time to read the posts
carefully. I certainly have not removed any words and in fact I have
tried to be very fair about moving comments and discussions and
retaining summaries. You may refer back to the first post:
http://dev.eclipse.org/newslists/news.eclipse.foundation/msg 01283.html
You will find that word you dislike on line 28.

- Bjorn
Re: [EDP] What is motivating this revision? [message #41036 is a reply to message #40943] Tue, 31 October 2006 17:01 Go to previous messageGo to next message
Bjorn Freeman-Benson is currently offline Bjorn Freeman-Benson
Messages: 335
Registered: July 2009
Senior Member
Dave wrote:
> +++I did not write any of the Foundation Bylaws.

My error - I did not know the history sufficiently well.

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

As I mentioned before, we (the EMO) have talked to the Board and the
Members about the issue. However, it is not my role to divulge what is
said in Board meetings - you'll have to talk to your Board member(s)[1].

[1] http://www.eclipse.org/org/foundation/directors.php

>> Dave, I am definitely open to any suggestions and ideas about how to make
>> the Architecture Council effective. ...
> If that's true, then as discussed earlier, the EMO should ...
> engage with Board members to obtain
> additional time from Architecture Council members, or both.

Assuming that we have done that and we're still where we are, what other
concrete suggestions do you have for improving the effectiveness of the
Architecture Council?

- Bjorn
Re: [EDP] What is motivating this revision? [message #41064 is a reply to message #40943] Tue, 31 October 2006 17:09 Go to previous messageGo to next message
Bjorn Freeman-Benson is currently offline Bjorn Freeman-Benson
Messages: 335
Registered: July 2009
Senior Member
Dave,
You raise a point that the community-at-large is also probably
interested in:

Dave wrote:
> +++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?

This revised development process is motivated by the desire to have the
process-as-written match the process-as-practiced [1]. Eclipse currently
does not have Validation reviews and thus they have been removed from
the process document.

[1]
http://eclipse-projects.blogspot.com/2006/09/your-comments-o n-eclipse-development.html

- Bjorn
Re: [EDP] What is motivating this revision? [message #41156 is a reply to message #41036] Wed, 01 November 2006 04:48 Go to previous messageGo to next message
Dave Bernstein is currently offline Dave Bernstein
Messages: 8
Registered: July 2009
Junior Member
Regarding the reasons why reviews are poorly attended, you make it sound as
if the only members with whom you spoke were board members, as a summary of
information gleaned from members queried outside board meetings would not
compromise board confidentiality. Without such a summary, productive
discourse on this item is impossible.

http://www.eclipse.org/org/foundation/council.php shows the Architecture
Council with 23 members, 5 of which were appointed by the Eclipse
Foundation. Frankly, I find it difficult to believe that the Strategic
Developers cannot be convinced to appropriately staff this Council. But if
that is the case, then I would appoint additional members as necessary to
create a Council capable of fulfilling its responsibilities.

Dave


"Bjorn Freeman-Benson" <bjorn.freeman-benson@eclipse.org> wrote in message
news:ei7vfv$n20$1@utils.eclipse.org...
> Dave wrote:
>> +++I did not write any of the Foundation Bylaws.
>
> My error - I did not know the history sufficiently well.
>
>> +++ Those might help. Did you query individual members to determine why
>> they weren't participating in reviews? If so, what did you learn?
>
> As I mentioned before, we (the EMO) have talked to the Board and the
> Members about the issue. However, it is not my role to divulge what is
> said in Board meetings - you'll have to talk to your Board member(s)[1].
>
> [1] http://www.eclipse.org/org/foundation/directors.php
>
>>> Dave, I am definitely open to any suggestions and ideas about how to
>>> make the Architecture Council effective. ...
>> If that's true, then as discussed earlier, the EMO should ...
> > engage with Board members to obtain
>> additional time from Architecture Council members, or both.
>
> Assuming that we have done that and we're still where we are, what other
> concrete suggestions do you have for improving the effectiveness of the
> Architecture Council?
>
> - Bjorn
Re: [EDP] What is motivating this revision? [message #41187 is a reply to message #41064] Wed, 01 November 2006 04:51 Go to previous messageGo to next message
Dave Bernstein is currently offline Dave Bernstein
Messages: 8
Registered: July 2009
Junior Member
"We're not going to do this because we're not doing it now" is a weak
justification.

Dave

"Bjorn Freeman-Benson" <bjorn.freeman-benson@eclipse.org> wrote in message
news:ei7vui$s6m$1@utils.eclipse.org...
> Dave,
> You raise a point that the community-at-large is also probably interested
> in:
>
> Dave wrote:
>> +++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?
>
> This revised development process is motivated by the desire to have the
> process-as-written match the process-as-practiced [1]. Eclipse currently
> does not have Validation reviews and thus they have been removed from the
> process document.
>
> [1]
> http://eclipse-projects.blogspot.com/2006/09/your-comments-o n-eclipse-development.html
>
> - Bjorn
Re: [EDP] What is motivating this revision? [message #41248 is a reply to message #41156] Thu, 02 November 2006 18:58 Go to previous messageGo to next message
Bjorn Freeman-Benson is currently offline Bjorn Freeman-Benson
Messages: 335
Registered: July 2009
Senior Member
Dave wrote:
> Without such a summary, productive
> discourse on this item is impossible.

You are invited to contact a different subset of the membership to
gather your own data - I fear that no matter what I provide, you will
not like it - far better that you gather your own summary and provide
conclusions from there.

> Frankly, I find it difficult to believe that the Strategic
> Developers cannot be convinced to appropriately staff this Council.

Again, I suggest you gather your own data about the staffing and the
Council. I have explained my understanding of the situation and you have
explained that you (effectively) don't believe me. There isn't anything
I can offer you to convince you, thus you will have to find the data you
seek elsewhere. At the risk of being repetitive, I suggest you gather
your own data from the Board and the Strategic Members.

- Bjorn
Re: [EDP] What is motivating this revision? [message #41275 is a reply to message #41248] Fri, 03 November 2006 19:09 Go to previous messageGo to next message
Dave Bernstein is currently offline Dave Bernstein
Messages: 8
Registered: July 2009
Junior Member
On the topic of why reviews are poorly attended, data gathered from members
would not be for me to like or dislike; it would aid me and others in both
assessing the proposed revision and suggesting constructive additions.
During the creation of the Eclipse governance model and development process,
critique and contribution from the membership was continuous; in the spirit
of openness and transparency, all of this information was available to
everyone in summary form.

I accept your characterization of the Architecture Council's lack of
effectiveness, and I believe that you believe the Strategic Developers
cannot be convinced to appropriate staff this Council. I simply disagree
with your belief. What concerns me the most is solving this problem by
defining it away: if the development process is sufficiently weakened, then
the Architectural Council's current contribution can be deemed satisfactory.

Dave


"Bjorn Freeman-Benson" <bjorn.freeman-benson@eclipse.org> wrote in message
news:eidf56$29h$1@utils.eclipse.org...
> Dave wrote:
>> Without such a summary, productive discourse on this item is impossible.
>
> You are invited to contact a different subset of the membership to gather
> your own data - I fear that no matter what I provide, you will not like
> it - far better that you gather your own summary and provide conclusions
> from there.
>
>> Frankly, I find it difficult to believe that the Strategic
>> Developers cannot be convinced to appropriately staff this Council.
>
> Again, I suggest you gather your own data about the staffing and the
> Council. I have explained my understanding of the situation and you have
> explained that you (effectively) don't believe me. There isn't anything I
> can offer you to convince you, thus you will have to find the data you
> seek elsewhere. At the risk of being repetitive, I suggest you gather your
> own data from the Board and the Strategic Members.
>
> - Bjorn
Re: [EDP] What is motivating this revision? [message #41304 is a reply to message #41275] Sat, 04 November 2006 00:54 Go to previous messageGo to next message
Bjorn Freeman-Benson is currently offline Bjorn Freeman-Benson
Messages: 335
Registered: July 2009
Senior Member
Dave wrote:
> What concerns me the most is solving this problem by
> defining it away: if the development process is sufficiently weakened, then
> the Architectural Council's current contribution can be deemed satisfactory.

It would seem then that rather than just complaining about the
situation, you could offer specific suggestions for improvement. To date
you have not offered any such suggestions for improving the Development
Process document that would solve this problem. (You have complained
about how the EMO has operationally handled the Architecture Council,
but even there I was unable to find any suggestions other than "stack
the council" in (a) and "replace the council" in [1].)

Making sure that I'm not missing some specific suggestions that you have
put forth, I carefully re-read all your comments on the newsgroup and
the wiki. I found 3 specific suggestions (1, 2, 3) and two vague
suggestions (a, b) - did I miss any?

(-) no specific suggestions in
http://dev.eclipse.org/newslists/news.eclipse.foundation/msg 01283.html
(1) specific suggestion not to call the Mentoring Council a Council and
instead call it a Coaching Squad in
http://dev.eclipse.org/newslists/news.eclipse.foundation/msg 01285.html
I disputed your interpretation but said that I would go with whatever
the community as a whole chose.
(-) no specific suggestions in
http://dev.eclipse.org/newslists/news.eclipse.foundation/msg 01287.html
(-) no specific suggestions in
http://dev.eclipse.org/newslists/news.eclipse.foundation/msg 01292.html
(a) implied suggestion that the process contain descriptions of the the
function and content of the proposed reviews in
http://dev.eclipse.org/newslists/news.eclipse.foundation/msg 01291.html
I added this suggestion to the wiki page
(-) somewhat vague operational suggestion to stack the Architecture
Council with new people in
http://dev.eclipse.org/newslists/news.eclipse.foundation/msg 01291.html
I disagreed with this suggestion as I do not believe that stacking an
group with extra people is the way to get the group to function.
(-)[1] no specific suggestions in
http://dev.eclipse.org/newslists/news.eclipse.foundation/msg 01298.html
(-) no specific suggestions in
http://dev.eclipse.org/newslists/news.eclipse.foundation/msg 01299.html
(-) no specific suggestions in
http://dev.eclipse.org/newslists/news.eclipse.foundation/msg 01302.html
(2) specific suggestions on language at
http://wiki.eclipse.org/index.php/Development_Process_2006_R evision#Principles
I will incorporate these suggestions in the next revision.
(b) vague suggestion to include explicit expectations (without offering
any suggestions of how to define those expectations) at
http://wiki.eclipse.org/index.php/Development_Process_2006_R evision#Quality_Culture
I would incorporate this suggestion if someone would provide
definitions, however "freedom from defects" is equally vague and pointless.
(3) suggestion to enable the EMO to trigger an "Openness Review" at
http://wiki.eclipse.org/index.php/Development_Process_2006_R evision@#Structure_and_Organization
I incorporated this suggestion.

So, to summarize: specific suggestions from you and others have been
incorporated. Further, I have tried to read between the lines of vague
suggestions in order to incorporate them into the wiki.

I believe I speak for the entire community when I say that we welcome
further *specific* suggestions for discussion and consideration while at
the same time pointing out that imprecision, complaints, and arguments
without specific remedies do not help the process.

- Bjorn
Re: [EDP] What is motivating this revision? [message #41365 is a reply to message #41304] Sun, 05 November 2006 09:17 Go to previous messageGo to next message
Dave Bernstein is currently offline Dave Bernstein
Messages: 8
Registered: July 2009
Junior Member
When asked the goal of the proposed process revision, you responded "The
goal of this revision is update the process-as-written to match the
process-as-practiced".



When asked how the process-as-written differs from the process-as-practiced,
you responded with 5 items. These items and my specific recommendations
appear below:



1. no Validation phase; yes Incubation phase:



Restore the Validation phase and its Checkpoint Review to the proposed
revision, as they are essential. "We currently don't implement this phase or
hold this review" is not a justification for removing it.



2. Sub-projects with sub-projects



Proceed with the proposed changes.



3. Architecture Council is ineffective



If you can't convince the Strategic Developers to appropriately staff the
Architecture Council, then find someone who can. Do not weaken the process
to the point where it no longers requires an effective Architecture Council.



4. Reviews are poorly attended



Proceed with the proposed changes, but I do not have sufficient data to be
confident that they will be sufficient.



5. The level of framework-ness (to coin a phrase) across projects is highly
variable



As I understand "framework-ness", this is an explicit responsibility of the
Architecture Council. Establish an effective Architecture Council, as
suggested in #3.



The proposed process revision contains many sections containing commentary
not relevant to any of the above 5 items, e.g. "Open Source Rules of
Engagement", "Quality Culture", "Collective Reputation", "Eclipse Ecosystem",
"Three Communities", "Clear and Concise", "Freedom and Autonomy", "Evolving",
"Just Enough Process", and "Requirements". Remove these sections from the
proposed revision.
Re: [EDP] What is motivating this revision? [message #41396 is a reply to message #41365] Mon, 06 November 2006 15:51 Go to previous messageGo to next message
Bjorn Freeman-Benson is currently offline Bjorn Freeman-Benson
Messages: 335
Registered: July 2009
Senior Member
Thank you - I copied your specific suggestions 1 and 5b to the wiki
page. I did not copy 2 and 4 because the wiki already includes those.
I was unable to figure what specific suggestions for the development
process are in 3 and 5a? I understand that you feel that either the EMO
management of, or the staffing of, the Architecture Council is
inadequate, but how do you propose to change the Development Process to
remedy this?

Dave wrote:
> These items and my specific recommendations
> appear below:
>
> 3. Architecture Council is ineffective
> If you can't convince the Strategic Developers to appropriately staff the
> Architecture Council, then find someone who can. Do not weaken the process
> to the point where it no longers requires an effective Architecture Council.
>
> 5. The level of framework-ness (to coin a phrase) across projects is highly
> variable
> As I understand "framework-ness", this is an explicit responsibility of the
> Architecture Council. Establish an effective Architecture Council, as
> suggested in #3.
Re: [EDP] What is motivating this revision? [message #41427 is a reply to message #41396] Tue, 07 November 2006 18:23 Go to previous message
Dave Bernstein is currently offline Dave Bernstein
Messages: 8
Registered: July 2009
Junior Member
Achieving an effective Architecture Council does not require a change to the
Development Process or the Bylaws. As I have repeatedly suggested,
accomplishing this requires the EMO to see this council properly staffed
through a combination of convincing the Strategic Developers to
appropriately assign and task their representatives, and appointing
additional personnel as required.

Dave

"Bjorn Freeman-Benson" <bjorn.freeman-benson@eclipse.org> wrote in message
news:einlmk$e86$1@utils.eclipse.org...
> Thank you - I copied your specific suggestions 1 and 5b to the wiki page.
> I did not copy 2 and 4 because the wiki already includes those.
> I was unable to figure what specific suggestions for the development
> process are in 3 and 5a? I understand that you feel that either the EMO
> management of, or the staffing of, the Architecture Council is inadequate,
> but how do you propose to change the Development Process to remedy this?
>
> Dave wrote:
>> These items and my specific recommendations
>> appear below:
>>
>> 3. Architecture Council is ineffective
>> If you can't convince the Strategic Developers to appropriately staff the
>> Architecture Council, then find someone who can. Do not weaken the
>> process to the point where it no longers requires an effective
>> Architecture Council.
>>
>> 5. The level of framework-ness (to coin a phrase) across projects is
>> highly variable
>> As I understand "framework-ness", this is an explicit responsibility of
>> the Architecture Council. Establish an effective Architecture Council, as
>> suggested in #3.
Previous Topic:Eclipse is 5 - Help Celebrate!
Next Topic:[EDP] Roadmap Process
Goto Forum:
  


Current Time: Sun Sep 21 22:21:31 GMT 2014

Powered by FUDForum. Page generated in 0.02578 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software