[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [eclipse.org-planning-council] A suggested topic for Planning Council Discussion
|
Ed,
No one has ever suggested that the Board could, should or would demand that
any particular feature or requirement be implemented.
But the Board can and does approve release review requirements, the IP
approval process and the development process.
But if I am reading this correctly, you're saying that you don't disagree
with the goal of raising the expectations, but that enforcing those with
sticks is misguided, and carrots would work better. Is that right?
> -----Original Message-----
> From: eclipse.org-planning-council-bounces@xxxxxxxxxxx
> [mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx] On Behalf Of
> Ed Merks
> Sent: Thursday, November 01, 2007 3:58 PM
> To: eclipse.org-planning-council
> Cc: eclipse.org-planning-council; eclipse.org-planning-council-
> bounces@xxxxxxxxxxx
> Subject: RE: [eclipse.org-planning-council] A suggested topic for
> Planning Council Discussion
>
> Doug,
>
> By the board you mean the Eclipse Board of Directors?
>
> I personally think the board is on very thin ice when it comes to
> spelling
> out functional requirements that represent work items for actual
> features
> to be implemented by projects. It should be pretty clear to everyone
> that
> coercion is act of desperation to be used as a last resort when all
> else
> fails and that only those who dish out the cash are in a position to
> have
> functional requirements. Now before someone jumps all over me, let me
> point out that I'm well aware that the whole Eclipse ecosystem and all
> the
> projects that exist in it are there at the sole discretion of the board
> and
> that of course there are many rules (import ones!) that projects are
> not
> just expected but in fact required to follow in order to have the
> privilege
> of existing within the board-mandated ecosystem. But that's not the
> same
> as saying the board can demand that PDE implement
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=109137 because the
> community
> is sick and tired of waiting for this important functional
> "requirement".
>
> I'm not really sure how best for anyone to influence the kinds of
> changes
> that we all want to see. Certainly one approach is to set the best of
> examples and entice others to follow it. Another is to actually step
> in
> and help out directly, but that's just a variation of the first
> approach.
> It's also good to make folks feel included in a larger group, i.e.,
> make
> them feel like participating members and thereby ensuring that they
> have a
> vested interest in both setting and meeting the expectations of this
> larger
> group. I think the Planning Council is the best example we have of
> this
> type of approach. So we ought to try to build on that. For example, I
> still believe strongly that Mike's earlier concerns about UI guidelines
> should not be forgotten. I don't agree we should try to enforce them,
> but
> I think some peer pressure and a hall of shame for violators will
> accomplish the same goal without the police force.
>
>
> Ed Merks/Toronto/IBM@IBMCA
> mailto: merks@xxxxxxxxxx
> 905-413-3265 (t/l 313)
>
>
>
>
>
> Doug Schaefer
> <DSchaefer@xxxxxx
> m>
> To
> Sent by: "eclipse.org-planning-council"
> eclipse.org-plann <eclipse.org-planning-
> council@eclip
> ing-council-bounc se.org>
> es@xxxxxxxxxxx
> cc
>
>
> Subject
> 11/01/2007 03:36 RE: [eclipse.org-planning-
> council]
> PM A suggested topic for
> Planning Council Discussion
>
> Please respond to
> "eclipse.org-plan
> ning-council"
> <eclipse.org-plan
> ning-council@ecli
> pse.org>
>
>
>
>
>
>
> Yes. This is the best practical approach.
>
> But the question remains. How does the board get the projects to meet
> requirements? The world sees Eclipse as a whole. One bad piece impacts
> the
> perception of the others. The projects are little kingdoms with 99%
> autonomy. We need to figure out how to influence into that environment.
>
> Doug Schaefer, QNX Software Systems
> Eclipse CDT Project Lead, http://cdtdoug.blogspot.com
>
>
> > -----Original Message-----
> > From: eclipse.org-planning-council-bounces@xxxxxxxxxxx
> > [mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx] On Behalf
> Of Ed
> > Merks
> > Sent: Thursday, November 01, 2007 3:04 PM
> > To: eclipse.org-planning-council
> > Cc: eclipse.org-planning-council; eclipse.org-planning-council-
> > bounces@xxxxxxxxxxx
> > Subject: RE: [eclipse.org-planning-council] A suggested topic for
> > PlanningCouncil Discussion
> >
> > +1
> >
> > I agree. Very well said. We need to focus on what's needed to get
> out
> > the builds and ultimately the release and resort to peer pressure to
> get
> > folks who stray back in line...
> >
> >
> > Ed Merks/Toronto/IBM@IBMCA
> > mailto: merks@xxxxxxxxxx
> > 905-413-3265 (t/l 313)
> >
> >
> >
> >
> >
> > jograham@sybase.c
> > om
> > Sent by:
> To
> > eclipse.org-plann "eclipse.org-planning-council"
> > ing-council-bounc
> <eclipse.org-planning-council@eclip
> > es@xxxxxxxxxxx se.org>
> >
> cc
> >
> > 11/01/2007 02:49
> Subject
> > PM RE: [eclipse.org-planning-
> council]
> > A suggested topic for
> > PlanningCouncil Discussion
> > Please respond to
> > "eclipse.org-plan
> > ning-council"
> > <eclipse.org-plan
> > ning-council@ecli
> > pse.org>
> >
> >
> >
> >
> >
> >
> > +1
> >
> > Well said, and I think this strikes a nice balance between what
> should be
> > done and what can be enforced.
> >
> > Regards,
> > John Graham
> > Eclipse Data Tools Platform PMC Chair
> > Staff Software Engineer, Sybase, Inc.
> > http://dataplat.blogspot.com/
> >
> >
> >
> >
> > "Gaff, Doug"
> > <doug.gaff@windri
> > ver.com>
> To
> > Sent by: "eclipse.org-planning-council"
> > eclipse.org-plann
> <eclipse.org-planning-council@eclip
> > ing-council-bounc se.org>
> > es@xxxxxxxxxxx
> cc
> >
> >
> Subject
> > 11/01/2007 02:32 RE: [eclipse.org-planning-
> council]
> > PM A suggested topic for
> > PlanningCouncil Discussion
> >
> > Please respond to
> > "eclipse.org-plan
> > ning-council"
> > <eclipse.org-plan
> > ning-council@ecli
> > pse.org>
> >
> >
> >
> >
> >
> >
> > All,
> >
> > As far as I?m concerned, the only reason to kick a project off the
> train
> > is
> > if they consistently fail to build and update their site at each
> > milestone.
> > Simply put, the ejection is because ?Project X keeps holding up the
> > release.? Furthermore, I think it should come to a vote by all of
> the
> > projects on the train to kick a single project off.
> >
> > Everything else should be a strongly encouraged optional requirement,
> and
> > we should use public humiliation to police those requirements, e.g.
> ?I
> > noticed that Project Y is not optimizing their jars, shame on you.
> Please
> > fix it.? Clearly there are technical must do?s that physically put a
> > project on the train, and they should be stated as such.
> >
> > Bottom line, I think we should err on the side of inclusion, and
> leave it
> > up the projects to prove that they can or can?t keep up with the
> milestone
> > schedule. If they can?t keep up, then their processes aren?t mature
> > enough.
> >
> > Doug G
> >
> > From: eclipse.org-planning-council-bounces@xxxxxxxxxxx
> > [mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx] On Behalf
> Of
> > Scott Lewis
> > Sent: Wednesday, October 31, 2007 5:17 PM
> > To: eclipse.org-planning-council
> > Subject: Re: [eclipse.org-planning-council] A suggested topic for
> > PlanningCouncil Discussion
> >
> > Hi Bjorn,
> >
> > Bjorn Freeman-Benson wrote:
> > Doug, (and everyone)
> > I agree - if there are no people or people hours, there will be no
> code,
> > no
> > matter how much the Board wishes for it to happen. One could argue (I
> have
> > argued) that the Board controls the people hours, so if they want to
> > define
> > a requirement, they should supply the resources, but somehow that
> logical
> > situation doesn't always come true.
> >
> > Do you really think it would poison the community if there were a
> two-
> > level
> > train?
> >
> >
> > I think it would poison the community to have a two-level train. I
> think
> > we would quickly see different requirements and EMO treatment (and
> member
> > company support) for the 'corporate-run' projects relative to all the
> > other
> > projects...those led by smaller companies and/or independents. Seems
> to
> > me
> > this would eventually lead to inequities that many committers would
> > consider unacceptable for a merit-and-value-based community.
> >
> >
> >
> > A "meet all the requirements" level (the gold medal) and a
> "simultaneously
> > release" level (the silver medal)? Maybe if the packages and the main
> > update site contained the gold seal projects, but that the silver
> projects
> > were also (if there was time to review the IP) available at the same
> time?
> >
> > It seems to me like this sort of classification would be inherently
> > detrimental to 'silver medal' projects and differential to 'gold
> medal'
> > projects. That is, it may say nothing about their usefulness, and/or
> > value
> > to be labeled as 'silver', but just the labeling by the membership
> and
> > foundation will lead to end-user biases...with lower adoption,
> tougher
> > distribution, etc., etc.
> >
> > It does seem to me that if the Board wants to mandate that the
> projects
> > have to do more/other in terms of integration/testing, etc for the
> release
> > train...and that the EMO should/must police/enforce the new
> rules...that
> > there should be some recognition that this implies some support from
> the
> > membership to do the work involved. There are many ways that I can
> think
> > of to do this (contributing integration testing resources, allowing
> > existing committers to work on related projects, etc., etc).
> Unfunded
> > mandates don't really work IMHO...either for the committer community
> or
> > for
> > the EMO.
> >
> > Scott
> >
> >
> >
> >
> >
> > - Bjorn
> >
> > Doug Schaefer wrote:
> > As for requirements, other than holding up the IP process I?m not
> sure
> > what
> > stick the EMO has to enforce projects meet the requirements. If
> projects
> > don?t have the resources or the mandate from the employers of the
> > resources
> > to do the work, it doesn?t happen. And if you kick projects off the
> train
> > because of that, that could poison the community. The best stick
> still is
> > influencing and that involves good communication channels open
> between
> the
> > requirers and requirees, and, of course, a reasonable set of
> requirements.
> > --
> >
> > [end of message]
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > eclipse.org-planning-council mailing list
> > eclipse.org-planning-council@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
> >
> > _______________________________________________
> > eclipse.org-planning-council mailing list
> > eclipse.org-planning-council@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
> > _______________________________________________
> > eclipse.org-planning-council mailing list
> > eclipse.org-planning-council@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
> >
> >
> > _______________________________________________
> > eclipse.org-planning-council mailing list
> > eclipse.org-planning-council@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
> _______________________________________________
> eclipse.org-planning-council mailing list
> eclipse.org-planning-council@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
>
>
> _______________________________________________
> eclipse.org-planning-council mailing list
> eclipse.org-planning-council@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
