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  |
 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.)
>>>> 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 #40816 is a reply to message #40682] |
Sat, 28 October 2006 09:50  |
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 |
Bjorn Freeman-Benson
Messages: 334
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 |
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 #41156 is a reply to message #41036] |
Wed, 01 November 2006 04:48 |
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 #41275 is a reply to message #41248] |
Fri, 03 November 2006 19:09 |
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 |
Bjorn Freeman-Benson
Messages: 334
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 |
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.
|
|
| | |
Goto Forum:
Current Time: Tue Apr 23 11:19:33 GMT 2024
Powered by FUDForum. Page generated in 0.05312 seconds |
] 
Search
Help
Register
Login
Home
