hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yu Li <car...@gmail.com>
Subject Re: [DISCUSS] Becoming a Committer
Date Thu, 21 Sep 2017 05:51:59 GMT
Allow me to quote the relative instructions in Spark (from
https://spark.apache.org/committers.html):
=======================
Becoming a Committer

To get started contributing to Spark, learn how to contribute
<https://spark.apache.org/contributing.html> – anyone can submit patches,
documentation and examples to the project.

The PMC regularly adds new committers from the active contributors, based
on their contributions to Spark. The qualifications for new committers
include:

   1. Sustained contributions to Spark: Committers should have a history of
   major contributions to Spark. An ideal committer will have contributed
   broadly throughout the project, and have contributed at least one major
   component where they have taken an “ownership” role. An ownership role
   means that existing contributors feel that they should run patches for this
   component by this person.
   2. Quality of contributions: Committers more than any other community
   member should submit simple, well-tested, and well-designed patches. In
   addition, they should show sufficient expertise to be able to review
   patches, including making sure they fit within Spark’s engineering
   practices (testability, documentation, API stability, code style, etc). The
   committership is collectively responsible for the software quality and
   maintainability of Spark.
   3. Community involvement: Committers should have a constructive and
   friendly attitude in all community interactions. They should also be active
   on the dev and user list and help mentor newer contributors and users. In
   design discussions, committers should maintain a professional and
   diplomatic approach, even in the face of disagreement.

The type and level of contributions considered may vary by project area –
for example, we greatly encourage contributors who want to work on mainly
the documentation, or mainly on platform support for specific OSes, storage
systems, etc.
=======================

So do we need a similar sector in our ref-guide? Maybe. More detailed list
of "prerequisites" like how many JIRAs one needs to resolve to become a
committer? IMHO no.

As a committer, it's normal to face the question about how to become one,
so I totally understand your question Mike. My experience is to share what
we did before given committer-ship for reference instead of telling them
what's required by the community.

And I think it's similar when some junior colleague ask us about "how to
get promoted" in daily work, maybe giving our own experience as an example
is better than some detailed list of prerequisite. Honestly I never saw
such a list in the companies I ever worked for, maybe because I'm too young
though (smile).

Only my point of view, hope it helps some way.

Best Regards,
Yu

On 21 September 2017 at 10:54, Mike Drob <mdrob@apache.org> wrote:

> Hi Andrew,
>
> Thanks for taking the time to respond. I certainly did not mean offense by
> starting this discussion - it largely stems from my own ignorance, which I
> hope is forgivable. Nor do I have any negative experiences to point to, and
> agree with you that I do not believe there is a "problem to correct" (using
> 'problem' at all originally was perhaps a lazy choice my part) - the goal
> here is to educate potential contributors and not at all to admonish or
> direct the PMC.
>
> The original impetus for me to ask the community about this came when a
> junior coworker asked me nearly the same question: "Hey, you're a
> committer, I'm interested in becoming a committer too, what should I do?"
> Telling him to act like a committer was helpful but not definitively so,
> because it begs the next question of how does a committer act. I realized
> that I had vague anecdotal answers - submit patches, do reviews,
> participate on the mailing lists, etc. - but I had could provide no
> assurances that my list would be complete or ordered correctly.
>
> Do you think that providing a list of desirable qualities for committers
> would be beneficial to the community, or poisonous? I can already see merit
> to both sides' arguments, and in my opinion it would come down to how the
> community implemented and used such a list. Would a prominent disclaimer
> that this is not a binding, exhaustive, or required list mitigate concerns
> you may have?
>
> I absolutely understand the desire for flexibility - if somebody comes in
> with a new category of contribution that the community previously hadn't
> considered then it would be a shame to block recognition solely because the
> person doesn't check some arbitrary boxes. But I also want to do right by
> new contributors - HBase is hard to use, and I think that makes it more
> difficult to contribute to, and very different from traditional libraries
> like commons-math, for instance (without disparaging their project and
> community in any way, of course).
>
> Maybe the better answer for my coworker's original question already exists
> in the docs, or on the mailing list archives, or somewhere on a blog post.
> There have been plenty of ApacheCon presentations about how to work with
> Apache communities. I admit that I could be approaching this from the wrong
> direction, and would be thrilled to have the information pointed out if
> it's been sitting right in front of me all along.
>
>
> Mike
>
>
>
> On Wed, Sep 20, 2017 at 5:05 PM, Andrew Purtell <apurtell@apache.org>
> wrote:
>
> > By the way I think "act like a committer and you'll become a committer"
> is
> > pretty good advice for anyone looking to enter into participation in an
> > open source community, and a reasonable yardstick to judge candidates who
> > have been nominated. I also have no objection to documenting a list of
> > favorable attributes. I would hope every PMCer voting on candidates will
> be
> > fair and remember how they judged previous candidates, and be objective.
> I
> > give everyone the presumption of acting in good faith and that's enough
> > (for me). What makes me allergic to this discussion is words like
> > "prerequisite" and the implication that our current process has been
> unfair
> > or is not aligned with the Apache Way. I think that case should be made
> if
> > we need to make it.
> >
> >
> > On Wed, Sep 20, 2017 at 2:54 PM, Andrew Purtell <apurtell@apache.org>
> > wrote:
> >
> > > > will lead to folks motivated wrongly, similar to oft maligned "resume
> > > driven development?"
> > >
> > > I find the need to have this discussion mildly offensive. Have we been
> > > unfair in offering committership? Do you have a specific example of
> > > something that looked improper? Can you name a committer whom you think
> > was
> > > offered committership without sufficient merit? Can you name any action
> > we
> > > have taken that smacks of "resume driven development"?
> > >
> > > I take the opposite view. I think the presumption of good faith in some
> > > communities has been ground down by inter-vendor conflicts and as a
> > result
> > > they are very litigious and everything must be super specified and "by
> > the
> > > book" according to some formal process that drains the spirit of the
> > Apache
> > > Way and is corrosive to everything that holds open source communities
> > > together. I don't think importing these ways to the HBase community is
> > > either necessary or wise at this time.
> > >
> > > I'd like nominations for committership and PMC to be addressed on a
> case
> > > by case basis. Perhaps we should have greater transparency in the
> welcome
> > > announcement.
> > >
> > >
> > > On Wed, Sep 20, 2017 at 11:48 AM, Mike Drob <mdrob@apache.org> wrote:
> > >
> > >>  Hi folks,
> > >>
> > >> I've been chatting with folks off and on about this for a while, and
> was
> > >> told that this made sense as a discussion on the dev@ list.
> > >>
> > >> How does the PMC select folks for committership? The most common
> answer
> > is
> > >> that folks should 'act like a committer' but that's painfully nebulous
> > and
> > >> easy to get sidetracked onto other topics. The problem is compounded
> > >> because what may be great on one project is inconsistently applied on
> > >> other
> > >> projects in the ASF, and yet we are all very tightly coupled as
> > >> communities
> > >> and as project dependencies.
> > >>
> > >> Ideally, this is something that we can document in the book. Misty
> > gently
> > >> pointed out http://hbase.apache.org/book.h
> > tml#_guide_for_hbase_committers
> > >> but
> > >> also noted that it's for what happens after somebody becomes a
> > committer.
> > >> Still, if the standard is "act like one until you become one" then
> it's
> > >> useful reading for people. Also, there doesn't seem to be any
> guidelines
> > >> like this for PMC.
> > >>
> > >> Is the list of prerequisites possible to articulate, or will it always
> > >> boil
> > >> down to "intangibles?" Is there a concern that providing a checklist
> > >> (perhaps a list of items necessary, but not sufficient) will lead to
> > folks
> > >> motivated wrongly, similar to oft maligned "resume driven
> development?"
> > >>
> > >> I'll kick off the discussion by saying that my personal yardstick of
> > "Can
> > >> I
> > >> trust this person's judgement regarding code/reviews" is probably too
> > >> vague
> > >> to be useful, and even worse is impossible for others to apply.
> > >>
> > >> Curiously,
> > >> Mike
> > >>
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Andrew
> > >
> > > Words like orphans lost among the crosstalk, meaning torn from truth's
> > > decrepit hands
> > >    - A23, Crosstalk
> > >
> >
> >
> >
> > --
> > Best regards,
> > Andrew
> >
> > Words like orphans lost among the crosstalk, meaning torn from truth's
> > decrepit hands
> >    - A23, Crosstalk
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message