Home » General (non-technical) » Eclipse Foundation » [EDP] Mentors Council or Coaching Squad?
| [EDP] Mentors Council or Coaching Squad? [message #40748] |
Fri, 27 October 2006 21:05  |
 Bjorn Freeman-Benson
Messages: 334
Registered: July 2009 |
Senior Member |
|
|
(Note: I have moved this conversation from the wiki page
( http://wiki.eclipse.org/index.php/Development_Process_2006_R evision) to
this newsgroup because the newsgroup seemed like a better place to have
a back-and-forth conversation. A summary of, and pointer to, this
conversation is on the wiki page.)
>>>>>>> Bjorn Freeman-Benson said:
>>>>>>> on behalf of the Architecture Council:
>>>>>>> At the October 2006 Architecture Council meeting in Esslingen
>>>>>>> (http://www.eclipse.org/org/councils/20061012ACMinutes.php),
>>>>>>> the Architecture Council rejected the idea of becoming
>>>>>>> responsible for mentoring new projects. Consequently, this
>>>>>>> process will need to include a fourth "Mentors Council".
>>>>>>> The rewritten sections are below.
>>>>>>>
>>>>>>> * The "Architecture Council" is responsible for reviewing
>>>>>>> the architecture of the Eclipse projects.
>>>>>>> * The "Mentors Council" is responsible for ensuring the
>>>>>>> Principles of the Development Process through mentorship.
>>>>>>> Membership in the Mentors Council is identical to that of
>>>>>>> the Planning and Architecture Councils described in the
>>>>>>> Bylaws through Strategic Membership, PMCs, and by
>>>>>>> appointment. The Mentors Council will, at least annually,
>>>>>>> recommend to the EMO(ED) Eclipse Members who have sufficient
>>>>>>> experience, wisdom, and time to be appointed to the Mentors
>>>>>>> Council and serve as mentors. Appointed members of the
>>>>>>> Mentors Council are appointed to three year renewable terms.
>>>>>>
>>>>>> Dave Bernstein said:
>>>>>> Addressing the need for mentorship with a 4th Council would
>>>>>> be highly inappropriate. The "Requirements", "Planning",
>>>>>> and "Architecture Councils" all have explicit roles in the
>>>>>> "Roadmap Workflow"; the proposed "Mentors Council" would have
>>>>>> no such role. Unlike the other three Councils, its members
>>>>>> would not discharge their responsibilities via intra-council
>>>>>> deliberation and collaboration. The need to mentor new
>>>>>> projects should instead be satified by establishing an
>>>>>> "Eclipse Coaching Squad" populated by distinguished
>>>>>> contributors chosen by the EMO. Each newly-formed Project
>>>>>> would be assigned a Coach from this Squad.
>>>>>
>>>>> Bjorn Freeman-Benson said:
>>>>> Dave, other than eleven different letters in the words, what
>>>>> is the difference between a Mentors Council and an Eclipse
>>>>> Coaching Squad?
>>>>
>>>> Rich Main said:
>>>> Dave beat me to the punch on this comment! The problem with
>>>> adding a fourth council for mentoring is that the current
>>>> councils have a certain level of authority within the
>>>> development process that really does not apply to mentoring.
>>>> Adding a mentoring council just muddies the waters
>>>> unnecessarily. It might be better to create a mentoring
>>>> working group or some such.
>>>
>>> Dave Bernstein said:
>>> I answered that question in my post above, Bjorn: a Mentors
>>> Council would not be involved in the Roadmap Process as are
>>> the other three councils, and unlike the other three Councils,
>>> its members would not discharge their responsibilities via
>>> intra-council deliberation and collaboration -- they would
>>> individually engage with personnel from new projects.
>>>
>> Bjorn Freeman-Benson said:
>> Rich, Dave: I guess I'm just not seeing the difference,
>> although perhaps that doesn't matter - this document is not
>> my document but rather our collective document so if your
>> reading is the consensus, I'm fine with that. I see that this
>> document (a) does not specify a role in the Roadmap process
>> for the Mentors Council and (b) I do envision the Mentors
>> Council meeting for cross-project collaboration and level
>> setting. Add to that the fact that (c) the Architecture Council
>> hasn't had a practical role in the Roadmap for a couple of
>> years and I don't see the difference. But that's just me.
>
> Dave Bernstein said:
> The only clues we have as to what you think a Mentor's Council
> would do are
>
> * the statement "The Mentors Council is responsible for ensuring
> the Principles of the Development Process through mentorship" above
>
> * the phrase "mentoring new projects" above
>
> * your recent comment that you "...envision the Mentors Council
> meeting for cross-project collaboration and level setting"
>
> Cross-project collaboration seems very different than mentoring,
> Bjorn; on exactly what would this proposed council collaborate?
> When you say "level setting", exactly what levels would this
> council set?
>
> If, as you say, "the Architecture Council hasn't had a practical role
> in the Roadmap for a couple of years", then there are two
> possibilities:
>
> * none of the proposed Roadmap Themes and Priorities have
> required architectural changes, and no changes have been required
> to maintain long-term architectural viability
>
> * the Architecture Council has abdicated its responsibilities, and
> the EMO has been negligent in not correcting the situation
>
> In either case, it would be suboptimal to dilute and obscure the
> Council concept by mis-naming a group charged with providing
> mentorship to new projects. Clarity and consistency is as important
> in organization as it is in architecture.
Dave, Rich: If the community prefers to call the mentoring group the
Coaching Squad rather than Council, I'm not going stand in their way.
The group will have the same behavior regardless of its name, so its
minor point. The group will meet from time to time to share experiences
and goals around mentoring and thus to ensure that all projects receives
a more or less consistent set of advice.
On the Architecture Council issue: thanks for telling me that I've done
a poor job - I'm always looking for that kind of detailed feedback :-)
If you'd like more information about the Architecture Council you could
talk to the current members, read the minutes
(http://www.eclipse.org/org/foundation/council.php), and talk to the
Board members (http://www.eclipse.org/org/foundation/directors.php). You
probably won't change your mind about how I've been negligent, but you
may learn more about the reality of the situation.
- Bjorn
|
|
|
| Re: [EDP] Mentors Council or Coaching Squad? [message #40973 is a reply to message #40748] |
Tue, 31 October 2006 06:34  |
Dave Bernstein
Messages: 8
Registered: July 2009 |
Junior Member |
|
|
If, as you say, the Architecture Council has been dysfunctional for years,
then by definition the EMO has been negligent in not correcting the
situation. Leading the Planning and Architecture Councils to produce the
Roadmap is an explicit EMO responsibility.
I made no comment about the quality of your work, Bjorn, as am ignorant of
your responsibilities.
Dave
"Bjorn Freeman-Benson" <bjorn.freeman-benson@eclipse.org> wrote in message
news:ehtsbo$vkp$1@utils.eclipse.org...
> (Note: I have moved this conversation from the wiki page
> ( http://wiki.eclipse.org/index.php/Development_Process_2006_R evision) to
> this newsgroup because the newsgroup seemed like a better place to have a
> back-and-forth conversation. A summary of, and pointer to, this
> conversation is on the wiki page.)
>
> >>>>>>> Bjorn Freeman-Benson said:
> >>>>>>> on behalf of the Architecture Council:
> >>>>>>> At the October 2006 Architecture Council meeting in Esslingen
> >>>>>>> (http://www.eclipse.org/org/councils/20061012ACMinutes.php),
> >>>>>>> the Architecture Council rejected the idea of becoming
> >>>>>>> responsible for mentoring new projects. Consequently, this
> >>>>>>> process will need to include a fourth "Mentors Council".
> >>>>>>> The rewritten sections are below.
> >>>>>>>
> >>>>>>> * The "Architecture Council" is responsible for reviewing
> >>>>>>> the architecture of the Eclipse projects.
> >>>>>>> * The "Mentors Council" is responsible for ensuring the
> >>>>>>> Principles of the Development Process through mentorship.
> >>>>>>> Membership in the Mentors Council is identical to that of
> >>>>>>> the Planning and Architecture Councils described in the
> >>>>>>> Bylaws through Strategic Membership, PMCs, and by
> >>>>>>> appointment. The Mentors Council will, at least annually,
> >>>>>>> recommend to the EMO(ED) Eclipse Members who have sufficient
> >>>>>>> experience, wisdom, and time to be appointed to the Mentors
> >>>>>>> Council and serve as mentors. Appointed members of the
> >>>>>>> Mentors Council are appointed to three year renewable terms.
> >>>>>>
> >>>>>> Dave Bernstein said:
> >>>>>> Addressing the need for mentorship with a 4th Council would
> >>>>>> be highly inappropriate. The "Requirements", "Planning",
> >>>>>> and "Architecture Councils" all have explicit roles in the
> >>>>>> "Roadmap Workflow"; the proposed "Mentors Council" would have
> >>>>>> no such role. Unlike the other three Councils, its members
> >>>>>> would not discharge their responsibilities via intra-council
> >>>>>> deliberation and collaboration. The need to mentor new
> >>>>>> projects should instead be satified by establishing an
> >>>>>> "Eclipse Coaching Squad" populated by distinguished
> >>>>>> contributors chosen by the EMO. Each newly-formed Project
> >>>>>> would be assigned a Coach from this Squad.
> >>>>>
> >>>>> Bjorn Freeman-Benson said:
> >>>>> Dave, other than eleven different letters in the words, what
> >>>>> is the difference between a Mentors Council and an Eclipse
> >>>>> Coaching Squad?
> >>>>
> >>>> Rich Main said:
> >>>> Dave beat me to the punch on this comment! The problem with
> >>>> adding a fourth council for mentoring is that the current
> >>>> councils have a certain level of authority within the
> >>>> development process that really does not apply to mentoring.
> >>>> Adding a mentoring council just muddies the waters
> >>>> unnecessarily. It might be better to create a mentoring
> >>>> working group or some such.
> >>>
> >>> Dave Bernstein said:
> >>> I answered that question in my post above, Bjorn: a Mentors
> >>> Council would not be involved in the Roadmap Process as are
> >>> the other three councils, and unlike the other three Councils,
> >>> its members would not discharge their responsibilities via
> >>> intra-council deliberation and collaboration -- they would
> >>> individually engage with personnel from new projects.
> >>>
> >> Bjorn Freeman-Benson said:
> >> Rich, Dave: I guess I'm just not seeing the difference,
> >> although perhaps that doesn't matter - this document is not
> >> my document but rather our collective document so if your
> >> reading is the consensus, I'm fine with that. I see that this
> >> document (a) does not specify a role in the Roadmap process
> >> for the Mentors Council and (b) I do envision the Mentors
> >> Council meeting for cross-project collaboration and level
> >> setting. Add to that the fact that (c) the Architecture Council
> >> hasn't had a practical role in the Roadmap for a couple of
> >> years and I don't see the difference. But that's just me.
> >
> > Dave Bernstein said:
> > The only clues we have as to what you think a Mentor's Council
> > would do are
> >
> > * the statement "The Mentors Council is responsible for ensuring
> > the Principles of the Development Process through mentorship" above
> >
> > * the phrase "mentoring new projects" above
> >
> > * your recent comment that you "...envision the Mentors Council
> > meeting for cross-project collaboration and level setting"
> >
> > Cross-project collaboration seems very different than mentoring,
> > Bjorn; on exactly what would this proposed council collaborate?
> > When you say "level setting", exactly what levels would this
> > council set?
> >
> > If, as you say, "the Architecture Council hasn't had a practical role in
> > the Roadmap for a couple of years", then there are two
> > possibilities:
> >
> > * none of the proposed Roadmap Themes and Priorities have
> > required architectural changes, and no changes have been required
> > to maintain long-term architectural viability
> >
> > * the Architecture Council has abdicated its responsibilities, and
> > the EMO has been negligent in not correcting the situation
> >
> > In either case, it would be suboptimal to dilute and obscure the
> > Council concept by mis-naming a group charged with providing
> > mentorship to new projects. Clarity and consistency is as important
> > in organization as it is in architecture.
>
> Dave, Rich: If the community prefers to call the mentoring group the
> Coaching Squad rather than Council, I'm not going stand in their way. The
> group will have the same behavior regardless of its name, so its minor
> point. The group will meet from time to time to share experiences and
> goals around mentoring and thus to ensure that all projects receives a
> more or less consistent set of advice.
>
> On the Architecture Council issue: thanks for telling me that I've done a
> poor job - I'm always looking for that kind of detailed feedback :-) If
> you'd like more information about the Architecture Council you could talk
> to the current members, read the minutes
> (http://www.eclipse.org/org/foundation/council.php), and talk to the Board
> members (http://www.eclipse.org/org/foundation/directors.php). You
> probably won't change your mind about how I've been negligent, but you may
> learn more about the reality of the situation.
>
> - Bjorn
|
|
| |
| Re: [EDP] Mentors Council or Coaching Squad? [message #41125 is a reply to message #41094] |
Tue, 31 October 2006 18:49 |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Bjorn,
I'm not sure this a totally clear/accurate summary of the meeting. ;-)
I would like to add to this comment, for the public record, that you do
your job exceedingly well in a tough situation and that we would be
nowhere without you helping to keep things focused and on track.
I think a lot of us expressed the feeling that we were already mentoring
new projects in our role as PMC leads/members and that the need for a
new set of specialized mentors seemed to be trying to fix a problem with
the existing mentors that could perhaps be addressed by ensuring that
the current PMC members are performing their role properly. I'm pretty
sure we were all agreed that mentoring is one of the things we are
already responsible for doing well...
Personally I really would like to see the Architecture Council spend
more time really talking about architecture but I that's proved
difficult; often we are spending more time on project management, with
this mentoring issue being a good example of that. It is a tough
problem, since much of the architecture discussion happens separately in
each project, and it's next to impossible to force anyone to do anything
they don't feel like doing...
Bjorn Freeman-Benson wrote:
> When talking to Jeff McAffer today, he expressed surprise at this:
>
>> Bjorn Freeman-Benson said:
>> on behalf of the Architecture Council:
>> At the October 2006 Architecture Council meeting in Esslingen
>> (http://www.eclipse.org/org/councils/20061012ACMinutes.php),
>> the Architecture Council rejected the idea of becoming
>> responsible for mentoring new projects.
>
> because he saw this as the perfect role for the Architecture Council -
> what better way to ensure the architectural coherence of Eclipse as a
> whole than to ensure the cooperation of the disparate projects?
|
|
| |
| Re: [EDP] Mentors Council or Coaching Squad? [message #41670 is a reply to message #41094] |
Fri, 10 November 2006 01:58 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.REMOVE.ca.ibm.com
Hmmm, I added this to the wiki then found this thread so I will repeat
here...
I was not at the meeting (unfortunately) but it is fundamentally
disappointing to me that the Architecture Council did not see mentoring
and sharing the vision of "Eclipseness" as a role they chose to play.
Roadmaps and processes aside, the very nature of an "architect" is "One
who designs and supervises the construction...". I strongly believe that
it is exactly the role of the Architecture Council to guide projects to
success through interactions such as mentoring and review participation.
Jeff
Bjorn Freeman-Benson wrote:
> When talking to Jeff McAffer today, he expressed surprise at this:
>
>> Bjorn Freeman-Benson said:
>> on behalf of the Architecture Council:
>> At the October 2006 Architecture Council meeting in Esslingen
>> (http://www.eclipse.org/org/councils/20061012ACMinutes.php),
>> the Architecture Council rejected the idea of becoming
>> responsible for mentoring new projects.
>
> because he saw this as the perfect role for the Architecture Council -
> what better way to ensure the architectural coherence of Eclipse as a
> whole than to ensure the cooperation of the disparate projects?
|
|
|
| Re: [EDP] Mentors Council or Coaching Squad? [message #41733 is a reply to message #41670] |
Fri, 10 November 2006 12:58 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Jeff,
I was there and I would interpret the reaction as one of: "Aren't we
already doing that?" and "If we aren't already doing that well---who
says we aren't?---shouldn't we just fix that problem rather than create
some new group, which is likely to suffer the same problems as the
current group?" I strongly disagree with any summary that concludes
that the council did not see this as a very important issue. We spent
more than an hour on this one topic, which I don't consider to be a
deeply technical one but rather an organizational/project management one
(which is not to imply it's not extremely important). After that first
hour, Rich and I had to leave to give a talk, so this was effectively
the only topic we discussed at the council. (It's clear that meetings
that overlap with other events will not be as well attended as they
should be.)
In my opinion, most of the problems we see (real and perceived) stem
from the fact that people simply do not have enough time to do all the
important things that need to be done. And not to point any fingers,
but I suspect that to a large extent the tools and the technology PMCs
can't cope with the volume of traffic within those domains, so perhaps
the focus should be more on such specific problems. Also, ask yourself
this question: how many of the people important to driving Eclipse's
architecture are typically present at the architecture council to help
make it effective and to make it fully an architecture council, i.e.,
with a focus on the design part of your architect definition, rather
than mostly with a focus on the supervisory part? I've only been to two
meetings (the first being more effective than the second, in my
opinion), and the next meeting is so close to EclipseCon that it's not
really a justifiable expense to travel for it.
In the end, high volumes of good intentions don't tend to address these
issues since the folks with the best intentions are the most likely to
be always too busy. There are certainly few people with better
intentions than Bjorn. The biggest problem I see is that once the
council is viewed as ineffective, lack of participation will just reduce
it's effectiveness further. It's kind of self fulfilling. It's for
these reasons that a solution which proposes to create a new group to
address the shortcomings of the current group seems destined to repeat
the mistakes...
Jeff McAffer wrote:
> Hmmm, I added this to the wiki then found this thread so I will repeat
> here...
>
> I was not at the meeting (unfortunately) but it is fundamentally
> disappointing to me that the Architecture Council did not see
> mentoring and sharing the vision of "Eclipseness" as a role they chose
> to play. Roadmaps and processes aside, the very nature of an
> "architect" is "One who designs and supervises the construction...". I
> strongly believe that it is exactly the role of the Architecture
> Council to guide projects to success through interactions such as
> mentoring and review participation.
>
> Jeff
>
> Bjorn Freeman-Benson wrote:
>> When talking to Jeff McAffer today, he expressed surprise at this:
>>
>>> Bjorn Freeman-Benson said:
>>> on behalf of the Architecture Council:
>>> At the October 2006 Architecture Council meeting in Esslingen
>>> (http://www.eclipse.org/org/councils/20061012ACMinutes.php),
>>> the Architecture Council rejected the idea of becoming
>>> responsible for mentoring new projects.
>>
>> because he saw this as the perfect role for the Architecture Council
>> - what better way to ensure the architectural coherence of Eclipse as
>> a whole than to ensure the cooperation of the disparate projects?
|
|
|
| Re: [EDP] Mentors Council or Coaching Squad? [message #41764 is a reply to message #41733] |
Fri, 10 November 2006 18:08 |
Bjorn Freeman-Benson
Messages: 334
Registered: July 2009 |
Senior Member |
|
|
Ed Merks wrote:
> shouldn't we just fix that problem rather than create
> some new group, which is likely to suffer the same problems as the
> current group?"
An excellent point. My claim is that the new group will be composed of
people who are interested in, and have the time to, do the job of
one-to-one project mentoring (answering questions, discussing problems,
explaining how they solved the same problem, etc) rather than a group of
people with a vaguely defined architecture mission.
It is entirely possible that the new mission will also be ineffective or
that the new, larger, more diverse, group of people will also be
ineffective. I prefer to remain optimistic that the mentoring role will
advance Eclipse's goals better than the architecture role has.
> And not to point any fingers,
> but I suspect that to a large extent the tools and the technology PMCs
> can't cope with the volume of traffic within those domains, so perhaps
> the focus should be more on such specific problems.
Another good point. However there are many new projects that are
starting outside the Tools and Technology projects, all of whom could
use mentoring. In fact, one might even argue that starting projects in
other top-level projects is detrimental to the long-term success of
Eclipse because all of the mentoring of those new projects comes from
the "group-think" of that one PMC - wouldn't it better to have at least
two different views of Eclipse, perhaps three different views of
Eclipse, to guide the 'open source social development' of a new project?
> Also, ask yourself
> this question: how many of the people important to driving Eclipse's
> architecture are typically present at the architecture council to help
> make it effective and to make it fully an architecture council, i.e.,
> with a focus on the design part of your architect definition, rather
> than mostly with a focus on the supervisory part?
A third good point. Are the architecture council members really the
right people to attend from each project? I cannot answer that - the
projects will have to answer for themselves.
> I've only been to two
> meetings (the first being more effective than the second, in my
> opinion),
Ed, could you explain how the June 28th meeting was effective?
http://www.eclipse.org/org/councils/20060628ACMinutes.php
As I recall, we talked about the JVM 1.4/1.5 issue and concluded that
everyone should just do what they should already be doing: making sure
their run-time dependency is explicit. There was also an action item for
various members to write up a wiki page and update their plans:
neither of which happened (or at least I don't recall them being
announced on the mailing list, a wiki search reveals nothing
http://wiki.eclipse.org/index.php/Special:Search?search=JVM& amp;go=Go
and a random sampling of project plans has some JVM information:
NO> http://www.eclipse.org/webtools/ > "Release Plan 2.0"
NO> http://www.eclipse.org/datatools/ > "Development" > "DTP 1.0 Project
Plan"
YES> http://www.eclipse.org/birt/phoenix/project/project_plan_R2_ 2_0.php
NO> http://wiki.eclipse.org/index.php/GMF_Project_Plan
We also talked about a common build infrastructure. There was a lack of
follow through from the AC members on their lists of problems and
prides. In spite of that, the Foundation held a releng workshop in the
fall and a common build structure is slowly evolving from that.
Maybe I'm being too demanding, but I don't see a lack of follow through
by the AC members as a sign of effectiveness.
- Bjorn
|
|
|
| Re: [EDP] Mentors Council or Coaching Squad? [message #41795 is a reply to message #41764] |
Fri, 10 November 2006 18:52 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------000607070602020907010003
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Bjorn,
Comments below.
Bjorn Freeman-Benson wrote:
> Ed Merks wrote:
>> shouldn't we just fix that problem rather than create some new group,
>> which is likely to suffer the same problems as the current group?"
>
> An excellent point. My claim is that the new group will be composed of
> people who are interested in, and have the time to, do the job of
> one-to-one project mentoring (answering questions, discussing
> problems, explaining how they solved the same problem, etc) rather
> than a group of people with a vaguely defined architecture mission.
I agree that it might well be very useful to have folks to act as
specialized mentors. The Eclipse processes are quite complex and are
changing, i.e., improving, all the time. So much of the mentoring will
be about helping understand those processes. I all too often need such
help myself...
>
> It is entirely possible that the new mission will also be ineffective
> or that the new, larger, more diverse, group of people will also be
> ineffective. I prefer to remain optimistic that the mentoring role
> will advance Eclipse's goals better than the architecture role has.
Yes, I'm generally an optimist so as long as we learn from past
mistakes, we won't be doomed to repeat them.
>
>> And not to point any fingers, but I suspect that to a large extent
>> the tools and the technology PMCs can't cope with the volume of
>> traffic within those domains, so perhaps the focus should be more on
>> such specific problems.
>
> Another good point. However there are many new projects that are
> starting outside the Tools and Technology projects, all of whom could
> use mentoring. In fact, one might even argue that starting projects in
> other top-level projects is detrimental to the long-term success of
> Eclipse because all of the mentoring of those new projects comes from
> the "group-think" of that one PMC - wouldn't it better to have at
> least two different views of Eclipse, perhaps three different views of
> Eclipse, to guide the 'open source social development' of a new project?
Yes, only multiple perspectives can give you an overall sense of the
diversity of perspectives.
>
>> Also, ask yourself this question: how many of the people important to
>> driving Eclipse's architecture are typically present at the
>> architecture council to help make it effective and to make it fully
>> an architecture council, i.e., with a focus on the design part of
>> your architect definition, rather than mostly with a focus on the
>> supervisory part?
>
> A third good point. Are the architecture council members really the
> right people to attend from each project? I cannot answer that - the
> projects will have to answer for themselves.
Certainly the folks I've met so far are highly intelligent and very (I
might even say, amazingly) cooperative, which is why I want to be sure
to deflect criticisms of the group. That being said, at the last
meeting, there was effectively no deep technical representation for the
platform itself, so that really doesn't help so much...
>
>> I've only been to two meetings (the first being more effective than
>> the second, in my opinion),
>
> Ed, could you explain how the June 28th meeting was effective?
> http://www.eclipse.org/org/councils/20060628ACMinutes.php
I had a feeling you'd bring up the fact that we've not yet begun our 5.0
porting wiki. But you did it so gently. ;-) This is kind of my point
about having the best of intentions not necessarily producing results.
To air my dirty linen in public, my tiny little development team is
currently still tied up with the second edition of the EMF book
work---you know how it goes, whenever you ask, it will be done in just
three short weeks---so I've been prototyping the 5.0 work in isolation
(and publicizing the results via attachments to 79768
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=79768>). But I have not
forgotten my promise...
>
> As I recall, we talked about the JVM 1.4/1.5 issue and concluded that
> everyone should just do what they should already be doing: making sure
> their run-time dependency is explicit. There was also an action item
> for various members to write up a wiki page and update their plans:
> neither of which happened (or at least I don't recall them being
> announced on the mailing list, a wiki search reveals nothing
> http://wiki.eclipse.org/index.php/Special:Search?search=JVM& amp;go=Go
> and a random sampling of project plans has some JVM information:
> NO> http://www.eclipse.org/webtools/ > "Release Plan 2.0"
> NO> http://www.eclipse.org/datatools/ > "Development" > "DTP 1.0
> Project Plan"
> YES> http://www.eclipse.org/birt/phoenix/project/project_plan_R2_ 2_0.php
> NO> http://wiki.eclipse.org/index.php/GMF_Project_Plan
>
> We also talked about a common build infrastructure. There was a lack
> of follow through from the AC members on their lists of problems and
> prides. In spite of that, the Foundation held a releng workshop in the
> fall and a common build structure is slowly evolving from that.
I thought that was itself an excellent result and we are definitely
willing to contribute our precious resource toward this effort.
>
> Maybe I'm being too demanding, but I don't see a lack of follow
> through by the AC members as a sign of effectiveness.
I guess I would say that the meeting itself seemed effective to me (it
was my first one) because we really talked in depth about some of the
architectural issues that I personally was most concerned about. I
think that helped create a better understanding of the issues we all
will face. But perhaps I set my effectiveness bar too low. ;-) I
certainly wouldn't suggest you should be less demanding since, to a very
great extent, it's your personal drive that keeps things from degrading
to the point of totally unacceptable...
>
> - Bjorn
--------------000607070602020907010003
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Bjorn,<br>
<br>
Comments below.<br>
<br>
<br>
Bjorn Freeman-Benson wrote:
<blockquote cite="midej2f79$5l8$1@utils.eclipse.org" type="cite">Ed
Merks wrote:
<br>
<blockquote type="cite">shouldn't we just fix that problem rather
than create some new group, which is likely to suffer the same problems
as the current group?" </blockquote>
<br>
An excellent point. My claim is that the new group will be composed of
people who are interested in, and have the time to, do the job of
one-to-one project mentoring (answering questions, discussing problems,
explaining how they solved the same problem, etc) rather than a group
of people with a vaguely defined architecture mission.
<br>
</blockquote>
I agree that it might well be very useful to have folks to act as
specialized mentors. The Eclipse processes are quite complex and are
changing, i.e., improving, all the time. So much of the mentoring will
be about helping understand those processes. I all too often need such
help myself...<br>
<blockquote cite="midej2f79$5l8$1@utils.eclipse.org" type="cite"><br>
It is entirely possible that the new mission will also be ineffective
or that the new, larger, more diverse, group of people will also be
ineffective. I prefer to remain optimistic that the mentoring role will
advance Eclipse's goals better than the architecture role has.
<br>
</blockquote>
Yes, I'm generally an optimist so as long as we learn from past
mistakes, we won't be doomed to repeat them.<br>
<blockquote cite="midej2f79$5l8$1@utils.eclipse.org" type="cite"><br>
<blockquote type="cite">And not to point any fingers, but I suspect
that to a large extent the tools and the technology PMCs can't cope
with the volume of traffic within those domains, so perhaps the focus
should be more on such specific problems. </blockquote>
<br>
Another good point. However there are many new projects that are
starting outside the Tools and Technology projects, all of whom could
use mentoring. In fact, one might even argue that starting projects in
other top-level projects is detrimental to the long-term success of
Eclipse because all of the mentoring of those new projects comes from
the "group-think" of that one PMC - wouldn't it better to have at least
two different views of Eclipse, perhaps three different views of
Eclipse, to guide the 'open source social development' of a new
project?
<br>
</blockquote>
Yes, only multiple perspectives can give you an overall sense of the
diversity of perspectives.<br>
<blockquote cite="midej2f79$5l8$1@utils.eclipse.org" type="cite"><br>
<blockquote type="cite">Also, ask yourself this question: how many of
the people important to driving Eclipse's architecture are typically
present at the architecture council to help make it effective and to
make it fully an architecture council, i.e., with a focus on the design
part of your architect definition, rather than mostly with a focus on
the supervisory part? </blockquote>
<br>
A third good point. Are the architecture council members really the
right people to attend from each project? I cannot answer that - the
projects will have to answer for themselves.
<br>
</blockquote>
Certainly the folks I've met so far are highly intelligent and very (I
might even say, amazingly) cooperative, which is why I want to be sure
to deflect criticisms of the group. That being said, at the last
meeting, there was effectively no deep technical representation for the
platform itself, so that really doesn't help so much...<br>
<blockquote cite="midej2f79$5l8$1@utils.eclipse.org" type="cite"><br>
<blockquote type="cite">I've only been to two meetings (the first
being more effective than the second, in my opinion), </blockquote>
<br>
Ed, could you explain how the June 28th meeting was effective?
<br>
<a class="moz-txt-link-freetext" href="http://www.eclipse.org/org/councils/20060628ACMinutes.php">http://www.eclipse.org/org/councils/20060628ACMinutes.php</a>
<br>
</blockquote>
I had a feeling you'd bring up the fact that we've not yet begun our
5.0 porting wiki. But you did it so gently. ;-) This is kind of my
point about having the best of intentions not necessarily producing
results. To air my dirty linen in public, my tiny little development
team is currently still tied up with the second edition of the EMF book
work---you know how it goes, whenever you ask, it will be done in just
three short weeks---so I've been prototyping the 5.0 work in isolation
(and publicizing the results via attachments to <a
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=79768">79768</a>).
But I have not forgotten my promise...<br>
<blockquote cite="midej2f79$5l8$1@utils.eclipse.org" type="cite"><br>
As I recall, we talked about the JVM 1.4/1.5 issue and concluded that
everyone should just do what they should already be doing: making sure
their run-time dependency is explicit. There was also an action item
for various members to write up a wiki page and update their plans:
neither of which happened (or at least I don't recall them being
announced on the mailing list, a wiki search reveals nothing
<br>
<a class="moz-txt-link-freetext" href=" http://wiki.eclipse.org/index.php/Special:Search?search=JVM& amp;go=Go"> http://wiki.eclipse.org/index.php/Special:Search?search=JVM& amp;amp;go=Go</a>
<br>
and a random sampling of project plans has some JVM information:
<br>
NO> <a class="moz-txt-link-freetext" href="http://www.eclipse.org/webtools/">http://www.eclipse.org/webtools/</a> > "Release Plan 2.0"
<br>
NO> <a class="moz-txt-link-freetext" href="http://www.eclipse.org/datatools/">http://www.eclipse.org/datatools/</a> > "Development" > "DTP
1.0 Project Plan"
<br>
YES>
<a class="moz-txt-link-freetext" href=" http://www.eclipse.org/birt/phoenix/project/project_plan_R2_ 2_0.php"> http://www.eclipse.org/birt/phoenix/project/project_plan_R2_ 2_0.php</a>
<br>
NO> <a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/index.php/GMF_Project_Plan">http://wiki.eclipse.org/index.php/GMF_Project_Plan</a>
<br>
<br>
We also talked about a common build infrastructure. There was a lack of
follow through from the AC members on their lists of problems and
prides. In spite of that, the Foundation held a releng workshop in the
fall and a common build structure is slowly evolving from that.
<br>
</blockquote>
I thought that was itself an excellent result and we are definitely
willing to contribute our precious resource toward this effort.<br>
<blockquote cite="midej2f79$5l8$1@utils.eclipse.org" type="cite"><br>
Maybe I'm being too demanding, but I don't see a lack of follow through
by the AC members as a sign of effectiveness.
<br>
</blockquote>
I guess I would say that the meeting itself seemed effective to me (it
was my first one) because we really talked in depth about some of the
architectural issues that I personally was most concerned about. I
think that helped create a better understanding of the issues we all
will face. But perhaps I set my effectiveness bar too low. ;-) I
certainly wouldn't suggest you should be less demanding since, to a
very great extent, it's your personal drive that keeps things from
degrading to the point of totally unacceptable...<br>
<blockquote cite="midej2f79$5l8$1@utils.eclipse.org" type="cite"><br>
- Bjorn
<br>
</blockquote>
<br>
</body>
</html>
--------------000607070602020907010003--
|
|
|
| Re: [EDP] Mentors Council or Coaching Squad? [message #41826 is a reply to message #41795] |
Fri, 10 November 2006 20:00 |
Bjorn Freeman-Benson
Messages: 334
Registered: July 2009 |
Senior Member |
|
|
Ed Merks wrote:
> I had a feeling you'd bring up the fact that we've not yet begun our 5.0
> porting wiki. But you did it so gently. ;-)
Like a falling brick, one might almost say
Falling brick humor: http://preview.tinyurl.com/th76l
> To air my dirty linen in public, my tiny little development team is
> currently still tied up with the second edition of the EMF book
To be honest, I think the EMF book will be more useful than a wiki page
about 5.0, but that's just me... (I'm saying "good choice of priorities,
Ed!").
> I certainly wouldn't suggest you should be less demanding ...
I guess I'm just frustrated that we (everyone on the Council, including
me) keeps promising to do things and then doesn't do them. And I ask
myself "what's the point of that?"
Anyway, we'll keep trying - I look forward to what Michael, Wenfeng,
Oisin, and John will produce:
http://www.eclipse.org/org/councils/20061012ACMinutes.php
- Bjorn
|
|
|
| Re: [EDP] Mentors Council or Coaching Squad? [message #41857 is a reply to message #41733] |
Sat, 11 November 2006 02:00 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.REMOVE.ca.ibm.com
Ed Merks wrote:
> Jeff,
>
> I was there and I would interpret the reaction as one of: "Aren't we
> already doing that?" and "If we aren't already doing that well---who
> says we aren't?---shouldn't we just fix that problem rather than create
> some new group, which is likely to suffer the same problems as the
> current group?"
Two comments:
- Apparently there are lots of new projects that could use help on their
way towards graduating and releasing. They may be getting help here and
there but at least some of them (anecdotally) are in need/desire of
explicit support/help.
- In fact I was particularly keen on NOT creating a separate group but
rather broadening/enhancing the scope of the AC to include propagation
of the architectural vision of Eclipse through active mentoring and
participation in reviews.
The interesting side effect of the "architects" (if you will) being
involved in a more diverse set of projects should be an increase in
cross-project understanding and cooperation.
> I strongly disagree with any summary that concludes
> that the council did not see this as a very important issue. We spent
I certainly did not mean to imply it was not seen as important simply
that the AC chose not to take on that role. I'm going to pick on the
logic here for a minute.
If it is very important and there isn't to be a different group but you
don't want to do it, how is this going to get done and who is going to
do it?
> hour, Rich and I had to leave to give a talk, so this was effectively
> the only topic we discussed at the council. (It's clear that meetings
> that overlap with other events will not be as well attended as they
> should be.)
Actually this is a concern I have since I am also on the Board and those
meetings often seem to overlap with at least some Council meetings. My
Clone is in the shop indefinitely so I'm doomed to miss various Council
meetings (even if I was on some of them).
> the focus should be more on such specific problems. Also, ask yourself
> this question: how many of the people important to driving Eclipse's
> architecture are typically present at the architecture council to help
> make it effective and to make it fully an architecture council, i.e.,
> with a focus on the design part of your architect definition, rather
> than mostly with a focus on the supervisory part? I've only been to two
> meetings (the first being more effective than the second, in my
> opinion), and the next meeting is so close to EclipseCon that it's not
> really a justifiable expense to travel for it.
The question of representation is a fine one. I honestly have no idea
what the composition of the AC is and how it got to be that way.
Sidenote: I certainly am not picking on the AC. I want mentors. I
happen to think that the "Architecture Council", simply considering the
name and a rough sketch of their purpose, is the right body to supply
said mentors.
Jeff
|
|
|
| Re: [EDP] Mentors Council or Coaching Squad? [message #41887 is a reply to message #41795] |
Sat, 11 November 2006 02:04 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.REMOVE.ca.ibm.com
Ed Merks wrote:
> Certainly the folks I've met so far are highly intelligent and very (I
> might even say, amazingly) cooperative, which is why I want to be sure
> to deflect criticisms of the group. That being said, at the last
> meeting, there was effectively no deep technical representation for the
> platform itself, so that really doesn't help so much...
You mean the Eclipse project? Who normally goes to the AC meetings for
Eclipse? Is that representation essential to the functioning of the AC?
Jeff
|
|
|
| Re: [EDP] Mentors Council or Coaching Squad? [message #41918 is a reply to message #41857] |
Sat, 11 November 2006 13:15 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Jeff,
It kind of sounds like we are in complete agreement. ;-)
Jeff McAffer wrote:
>
>
> Ed Merks wrote:
>> Jeff,
>>
>> I was there and I would interpret the reaction as one of: "Aren't we
>> already doing that?" and "If we aren't already doing that well---who
>> says we aren't?---shouldn't we just fix that problem rather than
>> create some new group, which is likely to suffer the same problems as
>> the current group?"
>
> Two comments:
> - Apparently there are lots of new projects that could use help on
> their way towards graduating and releasing. They may be getting help
> here and there but at least some of them (anecdotally) are in
> need/desire of explicit support/help.
As I said in the other note, I've needed for such help myself on more
than one occasion. And it can definitely be too hard to come by...
> - In fact I was particularly keen on NOT creating a separate group but
> rather broadening/enhancing the scope of the AC to include propagation
> of the architectural vision of Eclipse through active mentoring and
> participation in reviews.
I think this was a key point and perhaps a reason for misunderstandings.
The AC should already be performing this important role, and if it's not
doing that well, the problems should be addressed directly. If it's an
issue of resource, then adding more people to the group, rather than
creating a new group, would make sense. If it's an issue of skills
(there are lots of rules and they change a lot), then "we" need to help
mentor the mentors...
>
> The interesting side effect of the "architects" (if you will) being
> involved in a more diverse set of projects should be an increase in
> cross-project understanding and cooperation.
Yes. Like many, I tend to be very focused, perhaps overly so, and it's
nice to get the broader perspective at least once in a while.
>
>> I strongly disagree with any summary that concludes that the council
>> did not see this as a very important issue. We spent
>
> I certainly did not mean to imply it was not seen as important simply
> that the AC chose not to take on that role. I'm going to pick on the
> logic here for a minute.
> If it is very important and there isn't to be a different group but
> you don't want to do it, how is this going to get done and who is
> going to do it?
I think you've made the point, and I completely agree, that this is the
AC's role already and if it's being done poorly, that should be
addressed. I doubt problems are the lack of good intention, but
certainly in my own case, lack of time and to some extent lack of skill
are definitely a factor.
>
>> hour, Rich and I had to leave to give a talk, so this was
>> effectively the only topic we discussed at the council. (It's clear
>> that meetings that overlap with other events will not be as well
>> attended as they should be.)
>
> Actually this is a concern I have since I am also on the Board and
> those meetings often seem to overlap with at least some Council
> meetings. My Clone is in the shop indefinitely so I'm doomed to miss
> various Council meetings (even if I was on some of them).
>
>> the focus should be more on such specific problems. Also, ask
>> yourself this question: how many of the people important to driving
>> Eclipse's architecture are typically present at the architecture
>> council to help make it effective and to make it fully an
>> architecture council, i.e., with a focus on the design part of your
>> architect definition, rather than mostly with a focus on the
>> supervisory part? I've only been to two meetings (the first being
>> more effective than the second, in my opinion), and the next meeting
>> is so close to EclipseCon that it's not really a justifiable expense
>> to travel for it.
>
> The question of representation is a fine one. I honestly have no idea
> what the composition of the AC is and how it got to be that way.
>
> Sidenote: I certainly am not picking on the AC. I want mentors. I
> happen to think that the "Architecture Council", simply considering
> the name and a rough sketch of their purpose, is the right body to
> supply said mentors.
As I said, we seem to be in total agreement on this point. ;-)
>
> Jeff
|
|
|
| Re: [EDP] Mentors Council or Coaching Squad? [message #41949 is a reply to message #41887] |
Sat, 11 November 2006 13:20 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Jeff,
Normally Kevin Haaland would represent the platform. Certainly strong
technical representation from the platform is important if not essential
to the functioning of the AC. And I'm sure you, in particular, would
have significant contributions to make as well. :-)
Jeff McAffer wrote:
> Ed Merks wrote:
>> Certainly the folks I've met so far are highly intelligent and very
>> (I might even say, amazingly) cooperative, which is why I want to be
>> sure to deflect criticisms of the group. That being said, at the
>> last meeting, there was effectively no deep technical representation
>> for the platform itself, so that really doesn't help so much...
>
> You mean the Eclipse project? Who normally goes to the AC meetings
> for Eclipse? Is that representation essential to the functioning of
> the AC?
>
> Jeff
|
|
|
| Re: [EDP] Mentors Council or Coaching Squad? [message #41980 is a reply to message #41918] |
Sat, 11 November 2006 23:31 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.REMOVE.ca.ibm.com
Ed Merks wrote:
> Jeff,
>
> It kind of sounds like we are in complete agreement. ;-)
yeah but its more fun to make it seem as though we aren't ;-)
>> - In fact I was particularly keen on NOT creating a separate group but
>> rather broadening/enhancing the scope of the AC to include propagation
>> of the architectural vision of Eclipse through active mentoring and
>> participation in reviews.
> I think this was a key point and perhaps a reason for misunderstandings.
> The AC should already be performing this important role, and if it's not
> doing that well, the problems should be addressed directly. If it's an
> issue of resource, then adding more people to the group, rather than
> creating a new group, would make sense. If it's an issue of skills
> (there are lots of rules and they change a lot), then "we" need to help
> mentor the mentors...
Ok. I thought the original proposal was to enhance the AC with more
members and this additional role. Perhaps it is my misunderstanding...
>> Sidenote: I certainly am not picking on the AC. I want mentors. I
>> happen to think that the "Architecture Council", simply considering
>> the name and a rough sketch of their purpose, is the right body to
>> supply said mentors.
> As I said, we seem to be in total agreement on this point. ;-)
Darn!
Jeff
|
|
| | |
| Re: [EDP] Mentors Council or Coaching Squad? [message #42073 is a reply to message #42011] |
Sun, 12 November 2006 12:54 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Bjorn,
I certainly didn't mean to suggest that blame for the council being
ineffective lies at Kevin's feet for not being present. It's apparently
seen as ineffective even when he is present. ;-) The point is more that
spotty attendance or representation really won't help the council
function as well as perhaps it could. So while listening to Kevin
explain things from the platform's perspective isn't a prerequisite for
effectiveness, it surely wouldn't hurt either...
Bjorn Freeman-Benson wrote:
> Ed Merks wrote:
>> Certainly strong
>> technical representation from the platform is important if not
>> essential to the functioning of the AC.
>
> I have to disagree - I think that the AC needs to be effective whether
> a platform representative shows up or not, just as it needs to be
> effective whether an EMF representative shows up or not. If the AC
> requires the presence of a platform representative, then it becomes
> "projects listening to Kevin explain things" and, while interesting,
> that's not an effective collaborative community body.
>
> - Bjorn
|
|
|
| Re: [EDP] Mentors Council or Coaching Squad? [message #42104 is a reply to message #42042] |
Sun, 12 November 2006 13:16 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Bjorn,
I really hope that I can dispel the notion that I oppose the AC
improving its mentoring role or that I oppose some other group taking on
such responsibilities. I don't recall anyone at the AC taking that
position. There are more comments to that effect below...
Bjorn Freeman-Benson wrote:
>>>> Jeff McAffer wrote:
>>>> - In fact I was particularly keen on NOT creating a separate group
>>>> but rather broadening/enhancing the scope of the AC to include
>>>> propagation of the architectural vision of Eclipse through active
>>>> mentoring and participation in reviews.
>>>
> >> Ed Merks wrote:
>>> I think this was a key point and perhaps a reason for
>>> misunderstandings. The AC should already be performing this
>>> important role, and if it's not doing that well, the problems should
>>> be addressed directly. If it's an issue of resource, then adding
>>> more people to the group, rather than creating a new group, would
>>> make sense. If it's an issue of skills (there are lots of rules and
>>> they change a lot), then "we" need to help mentor the mentors...
>
> Ed,
> Now I'm confused - I recall (and I copied into the minutes) that at
> the last AC meeting you were against having the AC do this mentoring
> role because mentoring was too process-oriented and not enough about
> architecture. Perhaps you meant that the AC should do architecture
> mentoring and that some other body should do process mentoring?
As I said, my reaction was: "Aren't we supposed to be doing this
already? Is the AC being judged as doing its given role so poorly right
now that there is a need to create a whole new group to fix the
problem?" I think the answers seem to be yes and yes at this point...
> If so, I disagree - I think it works much better to have universal
> mentors rather than "a mentor for these issues and another mentor for
> those issues and a third mentor for these other issues and ... etc".
I've personally found that good help is hard to come by. So if there
were three different folks I could go to for different kinds of help, as
a beggar for help, I'd most pleased. One stop shopping would be even
better, but beggars can't be choosers. So bring on the mentors I say.
Add then to the council, create a new group, or do whatever is deemed
appropriate. And if I'm personally doing a poor job of mentoring, help
me do a better one.
>
> - Bjorn
|
|
|
| Re: [EDP] Mentors Council or Coaching Squad? [message #42135 is a reply to message #42104] |
Sun, 12 November 2006 14:40 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.REMOVE.ca.ibm.com
Ed Merks wrote:
> Bjorn Freeman-Benson wrote:
>> Now I'm confused - I recall (and I copied into the minutes) that at
>> the last AC meeting you were against having the AC do this mentoring
>> role because mentoring was too process-oriented and not enough about
>> architecture. Perhaps you meant that the AC should do architecture
>> mentoring and that some other body should do process mentoring?
> As I said, my reaction was: "Aren't we supposed to be doing this
> already? Is the AC being judged as doing its given role so poorly right
> now that there is a need to create a whole new group to fix the
> problem?" I think the answers seem to be yes and yes at this point...
We are likely nit picking at this point but what the heck... The part
that confuses me is the conjoining of "the AC is not mentoring" and "we
need to create a new group". My understanding of the original proposal
was to have the AC do the mentoring. So the answers "should" be yes and
no.
Few people I have spoken to have opposed having mentors. There are
pragmatic issues sure but it appears to be a fundamentally good idea.
As such, people should not oppose mentoring on the basis that it
currently appears to need a new group, they should oppose the AC
declining to take on that role.
Jeff
|
|
|
| Re: [EDP] Mentors Council or Coaching Squad? [message #42166 is a reply to message #42104] |
Sun, 12 November 2006 17:23 |
Bjorn Freeman-Benson
Messages: 334
Registered: July 2009 |
Senior Member |
|
|
Ed Merks wrote:
> I really hope that I can dispel the notion that I oppose the AC
> improving its mentoring role or that I oppose some other group taking on
> such responsibilities. I don't recall anyone at the AC taking that
> position.
My sincere apologies then for misunderstanding what was said at the AC
meeting in Germany. I thought the statement about "processes are not
part of the AC role" was pretty definite but ok... water under the bridge...
> As I said, my reaction was: "Aren't we supposed to be doing this
> already? Is the AC being judged as doing its given role so poorly right
> now that there is a need to create a whole new group to fix the
> problem?"
Officially, currently the Architecture Council is "responsible for the
development, articulation, and maintenance of the Eclipse Platform
Architecture"
http://www.eclipse.org/org/documents/Eclipse%20BYLAWS%202003 _11_10%20Final.pdf#page=20
and then:
"This Council is responsible for providing an explicit description of
the architecture and syndicating this description among the Development
Teams, thereby protecting the architecture from inadvertent corruption.
The Architecture Council is also responsible for plotting the evolution
of the Architecture in response to the Purposes and Roadmap, which is
captured in an Architecture Plan. Policies established by the
Architecture Council are limited to the domain of architecture, e.g. the
identification of immutable interfaces;"
http://www.eclipse.org/org/documents/Eclipse%20Development%2 0Process%202003_11_09%20FINAL.pdf#page=3
and then:
"The Architecture Council produces an Architecture Plan that describes
the architecture changes required to achieve these themes and
priorities, or required to maintain long-term architectural viability."
http://www.eclipse.org/org/documents/Eclipse%20Development%2 0Process%202003_11_09%20FINAL.pdf#page=6
I read these as meaning that the AC is responsible for the architecture
portion of the Roadmap (the Architecture Plan). I guess one could read
"syndicating" as mentoring, but I don't see mentoring mentioned
explicitly anywhere. Furthermore, I read "limited to the domain of
architecture" to mean that even if there where AC mentors, they wouldn't
provide advice on social aspects (how to create/foster a community) or
process issues (those reviews and that IP stuff) of Eclipse open source.
But, hey, if we're all in agreement that the AC should do these kind of
things, I'm happy to put that into the Development Process document and
work towards making that happen. I have no desire to create a fourth
group - I only proposed it because the AC had appeared to reject a
mentoring role.
- Bjorn
|
|
|
| Re: [EDP] Mentors Council or Coaching Squad? [message #42206 is a reply to message #42135] |
Mon, 13 November 2006 15:33 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Jeff,
It seems to me that the original proposal was to form a new group but
that seemed questionable too me because I think the PMC leads (whoe are
typically also an AC member) should already perform that role. Being
against mentoring is like opposing motherhood. I had to leave the
meeting before discussions on this subject concluded, so perhaps my
opinion doesn't reflect the AC's conclusions after I left...
Jeff McAffer wrote:
>
>
> Ed Merks wrote:
>
>> Bjorn Freeman-Benson wrote:
>>
>>> Now I'm confused - I recall (and I copied into the minutes) that at
>>> the last AC meeting you were against having the AC do this mentoring
>>> role because mentoring was too process-oriented and not enough about
>>> architecture. Perhaps you meant that the AC should do architecture
>>> mentoring and that some other body should do process mentoring?
>>
>> As I said, my reaction was: "Aren't we supposed to be doing this
>> already? Is the AC being judged as doing its given role so poorly
>> right now that there is a need to create a whole new group to fix the
>> problem?" I think the answers seem to be yes and yes at this point...
>
>
> We are likely nit picking at this point but what the heck... The part
> that confuses me is the conjoining of "the AC is not mentoring" and
> "we need to create a new group". My understanding of the original
> proposal was to have the AC do the mentoring. So the answers "should"
> be yes and no.
>
> Few people I have spoken to have opposed having mentors. There are
> pragmatic issues sure but it appears to be a fundamentally good idea.
> As such, people should not oppose mentoring on the basis that it
> currently appears to need a new group, they should oppose the AC
> declining to take on that role.
>
> Jeff
|
|
|
| Re: [EDP] Mentors Council or Coaching Squad? [message #42222 is a reply to message #42166] |
Mon, 13 November 2006 15:39 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Bjorn,
Comments below.
Bjorn Freeman-Benson wrote:
> Ed Merks wrote:
>
>> I really hope that I can dispel the notion that I oppose the AC
>> improving its mentoring role or that I oppose some other group taking
>> on such responsibilities. I don't recall anyone at the AC taking
>> that position.
>
>
> My sincere apologies then for misunderstanding what was said at the AC
> meeting in Germany. I thought the statement about "processes are not
> part of the AC role" was pretty definite but ok... water under the
> bridge...
I had to leave before discussions concluded, so perhaps things went in a
different direction after I left.
>
>> As I said, my reaction was: "Aren't we supposed to be doing this
>> already? Is the AC being judged as doing its given role so poorly
>> right now that there is a need to create a whole new group to fix the
>> problem?"
>
>
> Officially, currently the Architecture Council is "responsible for the
> development, articulation, and maintenance of the Eclipse Platform
> Architecture"
> http://www.eclipse.org/org/documents/Eclipse%20BYLAWS%202003 _11_10%20Final.pdf#page=20
>
>
> and then:
> "This Council is responsible for providing an explicit description of
> the architecture and syndicating this description among the
> Development Teams, thereby protecting the architecture from
> inadvertent corruption. The Architecture Council is also responsible
> for plotting the evolution of the Architecture in response to the
> Purposes and Roadmap, which is captured in an Architecture Plan.
> Policies established by the Architecture Council are limited to the
> domain of architecture, e.g. the identification of immutable interfaces;"
> http://www.eclipse.org/org/documents/Eclipse%20Development%2 0Process%202003_11_09%20FINAL.pdf#page=3
>
>
> and then:
> "The Architecture Council produces an Architecture Plan that describes
> the architecture changes required to achieve these themes and
> priorities, or required to maintain long-term architectural viability."
> http://www.eclipse.org/org/documents/Eclipse%20Development%2 0Process%202003_11_09%20FINAL.pdf#page=6
>
>
> I read these as meaning that the AC is responsible for the
> architecture portion of the Roadmap (the Architecture Plan). I guess
> one could read "syndicating" as mentoring, but I don't see mentoring
> mentioned explicitly anywhere. Furthermore, I read "limited to the
> domain of architecture" to mean that even if there where AC mentors,
> they wouldn't provide advice on social aspects (how to create/foster a
> community) or process issues (those reviews and that IP stuff) of
> Eclipse open source.
>
> But, hey, if we're all in agreement that the AC should do these kind
> of things, I'm happy to put that into the Development Process document
> and work towards making that happen. I have no desire to create a
> fourth group - I only proposed it because the AC had appeared to
> reject a mentoring role.
Certainly my opinion isn't the only one that counts, but I'd rather see
the leadership role of the AC be expanded than to define a new group and
I would argue that team/technical leads and PMC members should already
consider this a personal responsibility.
>
> - Bjorn
|
|
|
Goto Forum:
Current Time: Thu Apr 18 23:50:38 GMT 2024
Powered by FUDForum. Page generated in 0.03666 seconds |
] 
Search
Help
Register
Login
Home
