[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-planning-council] A suggested topic for PlanningCouncil Discussion

Scott,

Actually, this thread started out as David William's question about the
enforcement policy of the train's must do's; check the archive.  ;-)

I did try to inject Mike's concerns about usability from weeks gone by into
the discussion because I think it's important to avoid, as Mike says, just
giving up because it's a hard problem.  But that wasn't the original point
in the conversation.

I agree with Doug Gaff.  It's not sufficient for the board or the EMO just
to hand down edicts and expect they will get done because they'll be
enforced with an iron fist (nor am I suggesting that this is what the board
or EMO are doing, just that if they did, it wouldn't work).   I suspect
someone is reading this note and thinking, Ed, you're being passive
aggressive again.  :-P  Maybe I'd better quit before I've annoyed
everyone...


Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265  (t/l 313)




                                                                           
             Scott Lewis                                                   
             <slewis@composent                                             
             .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 05:14          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>                                                  
                                                                           
                                                                           




Although I agree with Ed about his process observations, I want to comment
that I thought this discussion started out with the Board desire to
*improve* the quality of the release train for an integrated end-user
experience.   I didn't think this was intended to become a referendum on
the release train projects individually (as I believe the dev
process/reviews, etc are designed to provide such guarantees...as John
points out), but rather how we were all going to get to the jointly-desired
result:  a high quality end-user experience for the release train.

Scott

Ed Merks wrote:
      Mike,

      I didn't suggest giving up.   But I am suggesting that I will not
      personally be on a quality police force.  I would be much happier
      with a
      growing release train of ever improving quality.  If we want to start
      kicking off the train cars we thing are crap, I believe this process
      will
      break down, especially considering that folks downstream from crappy
      cars
      will drop of by transitivity...

      I'm also not sure that 50 small projects are any different form 25
      projects
      of 1/2 the size, so I think this focus on the number of projects is
      misguided.  All that matters is quality not quantity and there are
      lots of
      things we could do to improve the quality.  And it's not just the
      code we
      ship that affects perceptions.  For example, some projects might
      consider
      paying more attention to their newsgroups...


      Ed Merks/Toronto/IBM@IBMCA
      mailto: merks@xxxxxxxxxx
      905-413-3265  (t/l 313)





                   "Mike

                   Milinkovich"

                   <mike.milinkovich
      To
                   @eclipse.org>
      "'eclipse.org-planning-council'"
                   Sent by:
      <eclipse.org-planning-council@eclip
                   eclipse.org-plann         se.org>

                   ing-council-bounc
      cc
                   es@xxxxxxxxxxx


      Subject
                                             RE:
      [eclipse.org-planning-council]
                   11/01/2007 04:24          A suggested topic for

                   PM                        PlanningCouncil  Discussion



                   Please respond to

                   mike.milinkovich@

                     eclipse.org;

                   Please respond to

                   "eclipse.org-plan

                     ning-council"

                   <eclipse.org-plan

                   ning-council@ecli

                       pse.org>







      I do not buy the argument that since you cannot measure quality
      objectively
      you should just give up. And yes, some mature projects could fall
      below
      this
      hypothetical bar.

      But as far as I'm concerned shipping a smaller, higher quality
      release
      train
      would be just dandy.



            -----Original Message-----
            From: Ed Merks [mailto:merks@xxxxxxxxxx]
            Sent: Thursday, November 01, 2007 4:06 PM
            To: mike.milinkovich@xxxxxxxxxxx; 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

            Mike,

            We don't have a bar for measuring quality objectively so that
            makes
            setting
            a bar for that extremely difficult.  How could we measure this
            and
            wouldn't
            some mature projects fall below this bar?

            I also don't think it's reasonable to assume that incubating
            things
            have
            low quality nor to assume they have CQs that we must cut back
            on;
            mature
            projects seem to generate an awful lot of CQs all on their own.

            I very much share your sense of concern about quality but I see
            no
            solution
            for policing it.  Peer pressure is the only viable solution
            I've heard
            so
            far.   Given resource from the foundation itself, e.g.,for
            testing or
            usability analysis, I'm sure a lot more could be accomplished,
            but if
            that
            resource is already streched just by the IP load, that doesn't
            seem a
            viable alternative either.  I think we're all ears for
            solutions...


            Ed Merks/Toronto/IBM@IBMCA
            mailto: merks@xxxxxxxxxx
            905-413-3265  (t/l 313)





                         "Mike
                         Milinkovich"
                         <mike.milinkovich
            To
                         @eclipse.org>
            "'eclipse.org-planning-council'"
                         Sent by:                  <eclipse.org-planning-
            council@eclip
                         eclipse.org-plann         se.org>
                         ing-council-bounc
            cc
                         es@xxxxxxxxxxx

            Subject
                                                   RE:
            [eclipse.org-planning-
            council]
                         11/01/2007 03:55          A suggested topic for
                         PM                        PlanningCouncil
            Discussion


                         Please respond to
                         mike.milinkovich@
                           eclipse.org;
                         Please respond to
                         "eclipse.org-plan
                           ning-council"
                         <eclipse.org-plan
                         ning-council@ecli
                             pse.org>






            Doug, Doug, Ed, et al,

            What you are suggesting is an even lower bar than what we have
            had in
            the
            past. At least on paper, if not in practice.

            The problem with this approach is it means that the release
            trains just
            get
            bigger and bigger and with no incremental improvement in the
            overall
            quality of what?s coming from Eclipse. Shipping a big bag of
            stuff that
            doesn?t work together is not going to help us build a
            reputation for
            quality. It will destroy it. And once you have destroyed a
            reputation
            for
            quality, it can take a generation (e.g. ~20 years) to get it
            back, if
            ever.

            As a purely practical matter, I honestly doubt that the Eclipse
            Foundation
            as the IP resources to review and approve all the CQs to ship
            30
            projects
            on the same day. So if you guys don?t come up with some rules
            that
            raise
            the bar and limit who has the process maturity and quality to
            get in,
            don?t
            get mad at me for making rude and arbitrary decisions J

            I completely understand that what you?re recommending is the
            simplest
            and
            easiest approach. But IMHO (a) it?s the wrong thing to do for
            the
            Eclipse
            community and (b) it is unlikely to work in practice.

            Mike Milinkovich
            Office: +1.613.224.9461 x228
            Mobile: +1.613.220.3223
            mike.milinkovich@xxxxxxxxxxx

            From: eclipse.org-planning-council-bounces@xxxxxxxxxxx
            [mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx] On
            Behalf Of
            Gaff, Doug
            Sent: Thursday, November 01, 2007 2:32 PM
            To: eclipse.org-planning-council
            Subject: RE: [eclipse.org-planning-council] A suggested topic
            for
            PlanningCouncil Discussion

            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