| Yup, the idea is that the project rep pushes their cause but there is still a bit broader understanding. It is absolutely not about control but about communication and coordination.
Tools is indeed under staffed for the number of projects.
I'm not sure that putting the AC in there is the right move. I think it mixes the agendas and mission. Certainly there are AC members who could be on the Tools PMC but i'm not sure that the AC as a whole should be the PMC (or even on the PMC).
Jeff On 2010-04-01, at 1:15 PM, John Arthorne wrote:
Thanks, I wasn't aware that the RT PMC
disallowed that. I can see both sides of the argument - you certainly
want the entire PMC to have visibility on the goings-on in each sub-project.
But having a representative from each member project on the PMC presumably
helps make sure that things keep moving forward in each sub-project? At
the very least it ensures that the size of the PMC is proportional to the
number of sub-projects so the PMC doesn't become too overloaded with approval
requests. Again, I have no idea what the problems are on the Tools project,
but thought that it had a relatively small PMC with quite a lot of sub-projects,
and that might be causing some of the delays that started this thread off.
John
Whoa there big fella! The RT PMC *explicitly* disallows
PMC members from approving their own stuff for exactly the reason that
it renders meaningless PMC oversight and visibility. We see great value
in one PMC member explaining things to other(s). The reason for having
each project represented is to facilitate communication and coordination
between the RT projects. Ultimately we want to present RT to the world
as some at least modestly coordinated affair. Each of the RT projects has
their own cut on that and we want those different viewpoints to be represented.
Each project's PMC member represents their project and pushes their agenda
but not to the exclusion of discussion and explanation.
Jeff
On 2010-04-01, at 12:06 PM, John Arthorne wrote:
I don't know anything about the inner workings of the Tools project, but
I noticed the RT project recently nominated a representative from each
sub-project onto the PMC. That way, each project can just take care of
their own elections and there is no worry about having to explain context
to a PMC member who knows little to nothing about the project. I wonder
if that would help with the Tools project as well. It seems unreasonable
for Doug or David to have to judge what is best for Mylyn or Buckminster,
or for them to be the gating factor in committer elections on those projects.
Anyway, I'm a complete outsider on this but thought I'd throw out the suggestion...
John
Doug Schaefer wrote on 04/01/2010 08:58:48 AM:
> There are discussions about bringing projects under the CDT. That
> way I can track things that I have more knowledge about (and care
> about for that matter). Other than that, no, it's what I meant by
> "little anyone wants to do about it". Technology benefits
from an
> foundation staffer managing it, Tools is pure volunteer with little
> vested interest above everything else we volunteer for and have
> vested interest in.
> On Thu, Apr 1, 2010 at 1:29 AM, Oisin Hurley <oisin.hurley@xxxxxxxxx>
wrote:
> > Tools is dysfunctional. There's no if, ands, or buts about it.
There seems
> > to be little anyone wants to do about it. So it is what it is,
for now.
> Have there been any proposals to change that state of affairs?
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
IMPORTANT: Membership in this list is generated by processes internal to
the Eclipse Foundation. To be permanently removed from this list,
you must contact emo@xxxxxxxxxxx to request removal.
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
IMPORTANT: Membership in this list is generated by processes internal to
the Eclipse Foundation. To be permanently removed from this list,
you must contact emo@xxxxxxxxxxx to request removal.
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation. To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal. |
