Re: Recognizing non-code contributions

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Recognizing non-code contributions

Sean Owen-3
(Let's move this thread to dev@ now as it is a general and important
community question. This was requested on members@)

On Thu, Aug 1, 2019 at 10:20 PM Matei Zaharia <[hidden email]> wrote:

>
> Our text on becoming a committer already says that we want committers who focus on our docs: https://spark.apache.org/committers.html. Just working on docs / books outside the project doesn’t make as much sense IMO.
>
> Matei
>
> On Aug 1, 2019, at 8:10 PM, Reynold Xin <[hidden email]> wrote:
>
> Not sure if ASF allows this but we can start some sort of “MVP” program recognizing non-code contributors...
>
> On Thu, Aug 1, 2019 at 7:18 PM Wenchen Fan <[hidden email]> wrote:
>>
>> I agree with the concerns about commit bit. If he maintains the Spark documentation himself, and doesn't need to commit code/merge PRs, then the commit bit is not needed but only as a form of recognition.
>>
>> Note that, we do have documentation in the Spark codebase. If he starts to reorganize/improve the document in the Spark codebase, and make significant progress, I think the commit bit is necessary and I'm +1 to make him a committer.
>>
>> On Fri, Aug 2, 2019 at 9:54 AM Felix Cheung <[hidden email]> wrote:
>>>
>>> Given the feedback here, I’d like to ask
>>>
>>> a) can this kind of documentation example guide be included into spark project proper or spark-website? Or can they be included in the newly mint ASF training repo?
>>>
>>> b) in the absence of “commit” even for documentation, can we come up with ways to recognize contributions to the community?
>>>
>>>
>>>
>>> On Thu, Aug 1, 2019 at 6:13 PM Hyukjin Kwon <[hidden email]> wrote:
>>>>
>>>> I agree with Sean in general, in particular, commit bit.
>>>>
>>>> Personal thought:
>>>>   I think committer should at least be used to the dev at some degree as primary.
>>>>   Other contributions should be counted of course (and I emphasize JIRA management) but it's secondary.
>>>>
>>>>
>>>> 2019년 8월 2일 (금) 오전 1:32, Sean Owen <[hidden email]>님이 작성:
>>>>>
>>>>> First let me say this is my opinion and a philosophical question on
>>>>> which people disagree, but I do feel pretty clear on my take, FWIW.
>>>>>
>>>>> If someone does a great job maintaining a Spark tutorial website,
>>>>> writes a good book, runs good Spark meetups, manages social media for
>>>>> the project or something, could such a person become a committer? It's
>>>>> often said on ASF lists, and it came up again this week, that 'yes'
>>>>> this person is 'committed' to the project so can be a 'committer'.
>>>>>
>>>>> I'd say 'no'. The reasoning above is more wordplay than an argument.
>>>>> Making someone a committer does a specific thing: gives them the
>>>>> commit bit. Someone who never commits anything never needs it, so,
>>>>> why? The counter-argument is, what does it hurt then? but I think this
>>>>> cuts the former way. (OK, it also gives them some additional power
>>>>> over others' code changes, but, same argument I think.)
>>>>>
>>>>> Of course the commit bit is widely understood as a form of recognition
>>>>> anyway. I think people really mean, this kind of person deserves
>>>>> recognition, and it's the only real official badge the project can
>>>>> hand out. I personally don't think that justifies use of the commit
>>>>> bit as purely recognition. If a lot of the ASF's legal scaffolding
>>>>> rests on responsible oversight of software releases, I suppose there
>>>>> is a distant and theoretical downside to giving commit access
>>>>> 'unnecessarily'.
>>>>>
>>>>> I'd prefer to simply recognize people in this category. But I admit,
>>>>> there's not a great way to do it other than say 'thank you'.
>>>>>
>>>>>
>>>>> What about someone who primarily writes doc changes, updates the
>>>>> website? maybe fixes tests? I'd say 'yes' that could be a basis for
>>>>> earning the commit bit, because those things require commit access to
>>>>> change. It doesn't have to be code per se. See for example Shane, who
>>>>> mostly tends the build and fixes scripts. Same argument.
>>>>>
>>>>>
>>>>> I'll say that someone's non-code, non-project contributions can factor
>>>>> in to deciding whether they should get the commit bit. Someone who
>>>>> does reviews and proved they can use commit access wisely, and know
>>>>> enough to tend some part of the code well, _and also demonstrates that
>>>>> expertise outside the project_, is a bit better than someone who
>>>>> doesn't. It's not irrelevant, but I think isn't sufficient on its own
>>>>> to justify getting the project code/doc commit bit.

---------------------------------------------------------------------
To unsubscribe e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Recognizing non-code contributions

Sean Owen-3
Yes, there's an interesting idea that came up on members@: should
there be a status in Spark that doesn't include the commit bit or
additional 'rights', but is formally recognized by the PMC? An MVP,
VIP, Knight of the Apache Foo project. I don't think any other project
does this, but don't think it's _prohibited_. This could recognize
long-time contributors of any kind (code, docs, external) for whom
it's not yet right to make a committer. The point would be
recognition, because there's really nothing short of that the project
can formally do. I personally am not sure it adds enough to justify
the process, and may wade too deeply into controversies about whether
this is just extra gatekeeping vs something helpful.

On Thu, Aug 1, 2019 at 11:09 PM Sean Owen <[hidden email]> wrote:

>
> (Let's move this thread to dev@ now as it is a general and important
> community question. This was requested on members@)
>
> On Thu, Aug 1, 2019 at 10:20 PM Matei Zaharia <[hidden email]> wrote:
> >
> > Our text on becoming a committer already says that we want committers who focus on our docs: https://spark.apache.org/committers.html. Just working on docs / books outside the project doesn’t make as much sense IMO.
> >
> > Matei
> >
> > On Aug 1, 2019, at 8:10 PM, Reynold Xin <[hidden email]> wrote:
> >
> > Not sure if ASF allows this but we can start some sort of “MVP” program recognizing non-code contributors...

---------------------------------------------------------------------
To unsubscribe e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Recognizing non-code contributions

Myrle Krantz
Hey Sean,

On 2019/08/02 13:20:56, Sean Owen <[hidden email]> wrote:

> Yes, there's an interesting idea that came up on members@: should
> there be a status in Spark that doesn't include the commit bit or
> additional 'rights', but is formally recognized by the PMC? An MVP,
> VIP, Knight of the Apache Foo project. I don't think any other project
> does this, but don't think it's _prohibited_. This could recognize
> long-time contributors of any kind (code, docs, external) for whom
> it's not yet right to make a committer. The point would be
> recognition, because there's really nothing short of that the project
> can formally do. I personally am not sure it adds enough to justify
> the process, and may wade too deeply into controversies about whether
> this is just extra gatekeeping vs something helpful.

Before adding an MVP status or the like, we should consider what kinds of effects you are trying to accomplish with it, and what other kinds of effects it might have.

Let me make a guess at what you are trying to accomplish with it.  Correct me please if I'm wrong:
* You want to encourage contributions that aren't just code contributions.  You recognize for example that good documentation is critical to bringing new contributors and committers to your project.  You recognize that other non-code contributions are also important to your project's success.
* You want to keep access to the code repositories "tight", ie minimized to people who you view as likely to be actively using that access for the goals of the project.  In particular, someone who writes tutorials, may not even want access to the spark code repositories.

If I missed something important, please let me know.

Other arguments I've heard for this (which you may or may not share)
* Fear of "diluting" the social value of committership in your project.

And here are some possible effects of creating a second category of recognition for non-code contributions which does not include commit access:
* things that aren't rewarded with committership are somehow viewed as being of lesser value to the project.  (It's already true in the industry that documentation writers, marketers, and event-organizers are sometime looked down on by programmers.)
* People doing these kinds of work may view the default location to do that work as being somewhere other than the spark code repositories, even if the code repository would be a better choice.  (For example, if a tutorial is kept in the code repository, coding examples will automatically show compile errors when there are breaking changes in an API.  But if documentation writers are told, implicitly, not to work in code repositories, the possibility of keeping code examples in the repository may never be considered.)
* People who want to work on spark may be more likely to chose to fork your repository rather than work with it directly.
* People who start off in other areas but have minor contributions to make to your code may never make those contributions (for example someone who does manual QA may never make that first step to automate manual work, or improve existing automated tests.  Documentation writers may never bother to create that pull request on your grammar errors for your inline documentation, so inline documentation may become a less-maintained second class citizen.)

Many of these effects are just variants of "Conway's law".  For those who haven't heard of it:

"organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." — M. Conway, 1967
https://en.wikipedia.org/wiki/Conway%27s_law

Best Regards,
Myrle

---------------------------------------------------------------------
To unsubscribe e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Recognizing non-code contributions

Sean Owen-3
On Sun, Aug 4, 2019 at 11:21 AM Myrle Krantz <[hidden email]> wrote:
> Let me make a guess at what you are trying to accomplish with it.  Correct me please if I'm wrong:
> * You want to encourage contributions that aren't just code contributions.  You recognize for example that good documentation is critical to bringing new contributors and committers to your project.  You recognize that other non-code contributions are also important to your project's success.

No, I think the position here was docs-only contributors _could_ be
committers. The "only coders can be committers" idea was I think a
misreading and accidental strawman from the members@ thread.

> * You want to keep access to the code repositories "tight", ie minimized to people who you view as likely to be actively using that access for the goals of the project.  In particular, someone who writes tutorials, may not even want access to the spark code repositories.

Yes, but in the narrow sense that someone with zero interaction with
the repo doesn't seem to need any repo access. That may actually be
uncontroversial?

There are tougher question here which we've always grappled with:
- What about someone who's stopped contributing but did some good work
in the past? they probably won't use the commit bit or contribute.
Generally I think we've recognized 'past-only' merit with the commit
bit.
- What about someone who's made a lot of code contributions but
doesn't review changes? have they demonstrated the skill that we need
people to deploy when they have the commit bit, which is knowing when
_others_ changes are OK to merge? Again I think we've only distantly
considered that, and there are committers who are almost entirely
contributors and not reviewers

... though I don't think we were questioning that here. (Maybe we should)


> Other arguments I've heard for this (which you may or may not share)
> * Fear of "diluting" the social value of committership in your project.

I think the goal is to tease apart being a committer as having a
particular important power in the repo, and being a committer as
recognition and valuable social status. I don't think there's a worry
that too many committers dilute the 'brand'. On the contrary, I'd say
we _don't_ want mere recognition to be a factor in handing out this
access? Recognition ought to be more freely available, without
debating the effects of giving commit access.


> And here are some possible effects of creating a second category of recognition for non-code contributions which does not include commit access:
> * things that aren't rewarded with committership are somehow viewed as being of lesser value to the project.  (It's already true in the industry that documentation writers, marketers, and event-organizers are sometime looked down on by programmers.)

Agree, though, again, I don't think anyone is saying docs-only
contributors can't be committers here.
Really I just think it's unfortunate how much the commit bit is
considered a 'reward' - maybe that's the problem.

You hit on one of my concerns. In theory some "VIP" status is better
than nothing, but if it's viewed as second-class status more than
anything, it backfires. That is, does it become perceived as a badge
of "someone the PMC has definitely decided won't be a committer,
because they decided to hand out VIP status instead"? It could be
worse than having no status, which indicates nothing about a PMC
decision.


> * People doing these kinds of work may view the default location to do that work as being somewhere other than the spark code repositories, even if the code repository would be a better choice.  (For example, if a tutorial is kept in the code repository, coding examples will automatically show compile errors when there are breaking changes in an API.  But if documentation writers are told, implicitly, not to work in code repositories, the possibility of keeping code examples in the repository may never be considered.)

Spark should have docs, quickstarts, examples. It already does in the
repo and people can and do contribute to them. So, I would agree this
is a risk if the project wasn't welcoming examples, docs, etc. But
that's not the position here nor reality -- I merge doc changes all
the time. Therefore I don't perceive this as related to whether or not
there's a VIP status. It would be a problem with not caring about
docs, full stop.


> * People who want to work on spark may be more likely to chose to fork your repository rather than work with it directly.
> * People who start off in other areas but have minor contributions to make to your code may never make those contributions (for example someone who does manual QA may never make that first step to automate manual work, or improve existing automated tests.  Documentation writers may never bother to create that pull request on your grammar errors for your inline documentation, so inline documentation may become a less-maintained second class citizen.)

Like, if not given the commit bit, they'll work only outside the repo?
I am not sure this is a risk? we're already talking about people who
contribute to Spark without being a committer. Would they stop if we
gave them VIP status but not the commit bit? (the risk there is as
above I think)

Or is the idea that if one doesn't have the rights to merge one's own
changes rapidly, they'll stop? That's better solved by ensuring that
good patches get reviewed and merged quickly, which is a big, separate
problem.

---------------------------------------------------------------------
To unsubscribe e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Recognizing non-code contributions

Myrle Krantz
On Sun, Aug 4, 2019 at 7:13 PM Sean Owen <[hidden email]> wrote:
On Sun, Aug 4, 2019 at 11:21 AM Myrle Krantz <[hidden email]> wrote:
> Let me make a guess at what you are trying to accomplish with it.  Correct me please if I'm wrong:
> * You want to encourage contributions that aren't just code contributions.  You recognize for example that good documentation is critical to bringing new contributors and committers to your project.  You recognize that other non-code contributions are also important to your project's success.

No, I think the position here was docs-only contributors _could_ be
committers. The "only coders can be committers" idea was I think a
misreading and accidental strawman from the members@ thread.

Can you be specific?  This status us supposed to serve as a form of recognition, right?  For who or what contributions?
 

> * You want to keep access to the code repositories "tight", ie minimized to people who you view as likely to be actively using that access for the goals of the project.  In particular, someone who writes tutorials, may not even want access to the spark code repositories.

Yes, but in the narrow sense that someone with zero interaction with
the repo doesn't seem to need any repo access. That may actually be
uncontroversial?

There are tougher question here which we've always grappled with:
- What about someone who's stopped contributing but did some good work
in the past? they probably won't use the commit bit or contribute.
Generally I think we've recognized 'past-only' merit with the commit
bit.

We have a saying at Apache: merit doesn't expire.  This is especially important for volunteer-based project work.  People's availability varies.  If the barrier to re-entry is low, you're more likely to get contributions from these people.  Contributions that can have a particularly high value because they are informed by a longer history of the project.

But the real question which I feel needs an answer here is: what's the harm you fear?  With modern source control, surely any harm is reversible?  If you're worried about people doing things outside their "abilities", then maybe the real question you need to ask when choosing committers is just: do they know to ask for help first in fragile parts of the code?  You may find that someone who is doesn't see themselves as a coder is *less* likely to break code than other committers.
 
- What about someone who's made a lot of code contributions but
doesn't review changes? have they demonstrated the skill that we need
people to deploy when they have the commit bit, which is knowing when
_others_ changes are OK to merge? Again I think we've only distantly
considered that, and there are committers who are almost entirely
contributors and not reviewers

This is really common in Apache projects.  But even if they never merge anyone else's PR, giving them the commit bit reduces the load on those who do merge PR's for their *own* PRs.  And increases the likelihood that they will eventually look at someone else's PR.  If you're trying to recognize someone who reviews other people's PRs, maybe you're looking for an honor *in addition to* committer rather than instead of?
 
... though I don't think we were questioning that here. (Maybe we should)


> Other arguments I've heard for this (which you may or may not share)
> * Fear of "diluting" the social value of committership in your project.

I think the goal is to tease apart being a committer as having a
particular important power in the repo, and being a committer as
recognition and valuable social status. I don't think there's a worry
that too many committers dilute the 'brand'. On the contrary, I'd say
we _don't_ want mere recognition to be a factor in handing out this
access? Recognition ought to be more freely available, without
debating the effects of giving commit access.

If the only question is "commitment" to the project, then you shouldn't need to worry about people breaking things who have a commit bit.  People who are committed to the project won't break things on purpose, and they'll quickly learn to not break things on access too.  That's part of the definition of commitment.

We've never teases these things apart at Apache because it simply hasn't been necessary.  Just like in SVN there are (or were?  I hope an SVN committer jumps in here) committers for certain areas of the code.  Those areas of the code were only ever defined socially.  And that never caused them problems for *years* of development.  If n is the percent of code that an sub-module committer can touch, you can also imagine cases where n = 0%.  And I think every project over a certain complexity *implicitly* has sub-module committers.  People know about certain areas of the code and not about other areas of the code.  They know to get their stuff reviewed when they're working with code they're less familiar with.

> And here are some possible effects of creating a second category of recognition for non-code contributions which does not include commit access:
> * things that aren't rewarded with committership are somehow viewed as being of lesser value to the project.  (It's already true in the industry that documentation writers, marketers, and event-organizers are sometime looked down on by programmers.)

Agree, though, again, I don't think anyone is saying docs-only
contributors can't be committers here.
Really I just think it's unfortunate how much the commit bit is
considered a 'reward' - maybe that's the problem.

We really shouldn't treat committer status like a reward.  It's just a permission: permission to participate more fully in the project.  That permission includes, but is not limited to the commit bit.  We should be thanking people who accept those permissions because it means they intend to continue contributing to the project. 

You hit on one of my concerns. In theory some "VIP" status is better
than nothing, but if it's viewed as second-class status more than
anything, it backfires. That is, does it become perceived as a badge
of "someone the PMC has definitely decided won't be a committer,
because they decided to hand out VIP status instead"? It could be
worse than having no status, which indicates nothing about a PMC
decision.

I hadn't even thought about the possibility of it being a case of "damned by faint praise".  But you're right.  That is a possible concern. 



> * People who want to work on spark may be more likely to chose to fork your repository rather than work with it directly.
> * People who start off in other areas but have minor contributions to make to your code may never make those contributions (for example someone who does manual QA may never make that first step to automate manual work, or improve existing automated tests.  Documentation writers may never bother to create that pull request on your grammar errors for your inline documentation, so inline documentation may become a less-maintained second class citizen.)

Like, if not given the commit bit, they'll work only outside the repo?
I am not sure this is a risk? we're already talking about people who
contribute to Spark without being a committer. Would they stop if we
gave them VIP status but not the commit bit? (the risk there is as
above I think)

Or is the idea that if one doesn't have the rights to merge one's own
changes rapidly, they'll stop? That's better solved by ensuring that
good patches get reviewed and merged quickly, which is a big, separate
problem.

I've seen this happen.  Especially when merges start slowing down, people either stop contributing altogether or just work from their own fork.  If you have enough "non-meriging" committers in your volunteer "pipeline" you have a better chance of people stepping up and becoming "merging" committers.  And at very least you remove a roadblock to participation when you make someone a committer.  Otherwise, you could accidentally doom your project to a lifespan equal to the volunteer burnout cycle of your one most dedicated volunteer.  Or accidentally couple it too tightly to the economic interests of that person's employer.  Either way, you'll shorten your project's lifespan unnecessarily.  And that would be a shame, because Spark is a really awesome project.

Best,
Myrle
(Sorry Sean, I accidentally sent this to just you first.)
Reply | Threaded
Open this post in threaded view
|

Re: Recognizing non-code contributions

Sean Owen-3
In reply to this post by Sean Owen-3
Oops, I also failed to copy dev@

On Sun, Aug 4, 2019 at 3:06 PM Sean Owen <[hidden email]> wrote:

>
> On Sun, Aug 4, 2019 at 1:54 PM Myrle Krantz <[hidden email]> wrote:
> >> No, I think the position here was docs-only contributors _could_ be
> >> committers. The "only coders can be committers" idea was I think a
> >> misreading and accidental strawman from the members@ thread.
> >
> > Can you be specific?  This status us supposed to serve as a form of recognition, right?  For who or what contributions?
>
> This "VIP" status is purely theoretical, but if I were making it up?
> it would be for anyone, and any 'valuable' contribution to the
> community of any kind.
> Here I'm merely saying that nobody here suggested docs-only
> contributors could never be committers. That seemed to be what the
> members@ thread was taking on, as if the argument was that docs-only
> contributors are at best these "VIPs". I want to make sure this isn't
> predicated on a misunderstanding.
>
>
> > We have a saying at Apache: merit doesn't expire.  This is especially important for volunteer-based project work.  People's availability varies.  If the barrier to re-entry is low, you're more likely to get contributions from these people.  Contributions that can have a particularly high value because they are informed by a longer history of the project.
>
> I know, I'm also here at Apache :) I guess I'm just showing we have
> already taken a broad view of merit, consistent with Apache, when
> there are even reasonable arguments about defining committer merit
> more narrowly. This responds to the general notion I hear, that the
> PMC here is somehow out of line and needs reeducation.
>
>
> > But the real question which I feel needs an answer here is: what's the harm you fear?  With modern source control, surely any harm is reversible?  If you're worried about people doing things outside their "abilities", then maybe the real question you need to ask when choosing committers is just: do they know to ask for help first in fragile parts of the code?  You may find that someone who is doesn't see themselves as a coder is *less* likely to break code than other committers.
>
> This is a vital point. The argument is, what are you afraid of? how
> much harm can a committer do? The logical extreme is to give everyone
> commit access, which nobody appears to advocate. But where's the line?
> What 'merit' are we talking about when we say people earn merit and
> that's rewarded with committership? You said it: good judgment above
> all. We have a committer that only run builds and config and doesn't
> deal with code at all, and we agree that's good.
>
> That is I'm not sure we (speaking broadly for Spark) disagree
> substantively. Again the premise here was: somebody who hasn't and
> doesn't want to touch anything about the project or ASF. I'm surprised
> if there's an argument for making said person a committer; I thought
> this was the easiest of cases. Still, I am quite sure ASF projects
> have done this (and I disagreed). It's not crazy. But it's at least as
> un-crazy to decide said person should not be a committer. Hence
> surprise that this is prompting calls for reeducation.
>
>
> > If the only question is "commitment" to the project, then you shouldn't need to worry about people breaking things who have a commit bit.  People who are committed to the project won't break things on purpose, and they'll quickly learn to not break things on access too.  That's part of the definition of commitment.
>
> I still find this wordplay more than anything. Being a committer and
> earning merit doesn't reduce to merely being 'committed'. If you
> define 'committed' as 'won't break things on purpose, etc' then it's
> circular. OK, how do we decide what constitutes evidence of committed,
> etc. But at the least I'd suggest that both are a valid POV within
> "The Apache Way" which we can discuss.
>
>
> > We really shouldn't treat committer status like a reward.  It's just a permission: permission to participate more fully in the project.  That permission includes, but is not limited to the commit bit.  We should be thanking people who accept those permissions because it means they intend to continue contributing to the project.
>
> You say it shouldn't be a reward, and I agree, although that ship has
> sailed. But you say it's more than getting commit access, it's being
> publicly honored and thanked and shown trust, which sounds like a
> reward? I honestly think we agree in most cases, as I often say that
> we should make X a committer to enfranchise and further encourage a
> pattern of contribution backed by good judgment. I accept it
> inevitably functions like recognition and that's useful, so, roll with
> it.
>
> The answer may be that "VIP" is a bad idea, and I'm not pushing for
> it. I tabled it as something that might further this very same end:
> early and easy official recognition, to show trust and encourage
> contribution. We're really debating how high/low the committer bar
> should be, and if it's 'low', this idea does very little.
>
>
> > I've seen this happen.  Especially when merges start slowing down, people either stop contributing altogether or just work from their own fork.  If you have enough "non-meriging" committers in your volunteer "pipeline" you have a better chance of people stepping up and becoming "merging" committers.  And at very least you remove a roadblock to participation when you make someone a committer.  Otherwise, you could accidentally doom your project to a lifespan equal to the volunteer burnout cycle of your one most dedicated volunteer.  Or accidentally couple it too tightly to the economic interests of that person's employer.  Either way, you'll shorten your project's lifespan unnecessarily.  And that would be a shame, because Spark is a really awesome project.
>
> On this I entirely agree. It's a different debate, but one we've had a
> lot over time: while there are possibly risks in adding someone as a
> committer, there are risks in not doing so too. You might find others
> on the PMC diverge more from your position, and I don't think it's a
> secret that I think the PMC has been a little overly conservative. The
> debate is reasonable (and visible on private@), and in-bounds w.r.t.
> The Apache Way. It needs to evolve, but, is not broken. I actually
> think members@ would do well to hear more in-bounds but diverging
> opinions, from good-faith and smart people from a different project.
> There are real, subtle questions here. A few people have gotten pretty
> dismissive of the learned experience of some large, successful ASF
> projects.

---------------------------------------------------------------------
To unsubscribe e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Recognizing non-code contributions

Myrle Krantz


On Sun, Aug 4, 2019 at 10:06 PM Sean Owen <[hidden email]> wrote:
Oops, I also failed to copy dev@

On Sun, Aug 4, 2019 at 3:06 PM Sean Owen <[hidden email]> wrote:
>
> On Sun, Aug 4, 2019 at 1:54 PM Myrle Krantz <[hidden email]> wrote:
> >> No, I think the position here was docs-only contributors _could_ be
> >> committers. The "only coders can be committers" idea was I think a
> >> misreading and accidental strawman from the members@ thread.
> >
> > Can you be specific?  This status us supposed to serve as a form of recognition, right?  For who or what contributions?
>
> This "VIP" status is purely theoretical, but if I were making it up?
> it would be for anyone, and any 'valuable' contribution to the
> community of any kind.
> Here I'm merely saying that nobody here suggested docs-only
> contributors could never be committers. That seemed to be what the
> members@ thread was taking on, as if the argument was that docs-only
> contributors are at best these "VIPs". I want to make sure this isn't
> predicated on a misunderstanding.

So... events coordinators?  I'd still make them committers.  I guess I'm still struggling to understand what problem making people VIP's without giving them committership is trying to solve.

It also just occurred to me this morning: There are actually other privileges which go along with the "commit-bit" other than the ability to commit at will to the project's repos: people who are committers get an Apache e-mail address, and they get discounted entry to ApacheCon.  People who are committers also get added to our committers mailing list, and are thus a little easier to integrate into our foundation-wide efforts.

To apply this to the example above, the Apache e-mail address can make it a tad easier for an event coordinator to conduct official business for a project.

> > We have a saying at Apache: merit doesn't expire.  This is especially important for volunteer-based project work.  People's availability varies.  If the barrier to re-entry is low, you're more likely to get contributions from these people.  Contributions that can have a particularly high value because they are informed by a longer history of the project.
>
> I know, I'm also here at Apache :) I guess I'm just showing we have
> already taken a broad view of merit, consistent with Apache, when
> there are even reasonable arguments about defining committer merit
> more narrowly. This responds to the general notion I hear, that the
> PMC here is somehow out of line and needs reeducation.

I don't think the PMC is "out of line".  I advocate for ease of access to other projects too.  (For example: https://twitter.com/myrleKrantz/status/1110475989941932038).  I do it because I think it will be helpful to the projects.  But it absolutely is true that every project decides for themselves what obstacles to access they want to put in to place.  As long as they are being equitable while doing that, the projects are within their rights.
 
> > But the real question which I feel needs an answer here is: what's the harm you fear?  With modern source control, surely any harm is reversible?  If you're worried about people doing things outside their "abilities", then maybe the real question you need to ask when choosing committers is just: do they know to ask for help first in fragile parts of the code?  You may find that someone who is doesn't see themselves as a coder is *less* likely to break code than other committers.
>
> This is a vital point. The argument is, what are you afraid of? how
> much harm can a committer do? The logical extreme is to give everyone
> commit access, which nobody appears to advocate. But where's the line?
> What 'merit' are we talking about when we say people earn merit and
> that's rewarded with committership? You said it: good judgment above
> all. We have a committer that only run builds and config and doesn't
> deal with code at all, and we agree that's good.

There are some people who will advocate that everyone should receive commit access.  SVN is an example of this, and they had great success with that approach.

But that's not what I'm arguing.  I'm arguing that you can safely give commit access to anyone for whom you're reasonably certain they will do no harm.  And your certainty of that can actually be much higher with non-coding committers.  So if someone suggests a non-coding contributor for committer, it should be fairly easy to say "yes".  Especially if you're on a project like Spark where PMC ⊂ committers.
 
> That is I'm not sure we (speaking broadly for Spark) disagree
> substantively. Again the premise here was: somebody who hasn't and
> doesn't want to touch anything about the project or ASF. I'm surprised
> if there's an argument for making said person a committer; I thought
> this was the easiest of cases. Still, I am quite sure ASF projects
> have done this (and I disagreed). It's not crazy. But it's at least as
> un-crazy to decide said person should not be a committer. Hence
> surprise that this is prompting calls for reeducation.

Some of the rhetoric on members@ was overly harsh.  You're certainly not crazy. : o)
 
> > If the only question is "commitment" to the project, then you shouldn't need to worry about people breaking things who have a commit bit.  People who are committed to the project won't break things on purpose, and they'll quickly learn to not break things on access too.  That's part of the definition of commitment.
>
> I still find this wordplay more than anything. Being a committer and
> earning merit doesn't reduce to merely being 'committed'. If you
> define 'committed' as 'won't break things on purpose, etc' then it's
> circular. OK, how do we decide what constitutes evidence of committed,
> etc. But at the least I'd suggest that both are a valid POV within
> "The Apache Way" which we can discuss.

Some of that circularity is necessary.  When you give people added karma for a project, you are guessing what they are going to do with it.  You can't know claim that someone you give committership is actually going to merge PRs until they do it.  You have to try and see.  So the circularity is there for all of your potential committers.
 
> > We really shouldn't treat committer status like a reward.  It's just a permission: permission to participate more fully in the project.  That permission includes, but is not limited to the commit bit.  We should be thanking people who accept those permissions because it means they intend to continue contributing to the project.
>
> You say it shouldn't be a reward, and I agree, although that ship has
> sailed. But you say it's more than getting commit access, it's being
> publicly honored and thanked and shown trust, which sounds like a
> reward? I honestly think we agree in most cases, as I often say that
> we should make X a committer to enfranchise and further encourage a
> pattern of contribution backed by good judgment. I accept it
> inevitably functions like recognition and that's useful, so, roll with
> it.

There is a misunderstanding here, based on a clumsy choice of words on my part.  Let me try to rephrase.  Committership is not a reward that the PMC gives to the individual contributor.  Committership is a reward that the individual contributor gives to the PMC.
 
> The answer may be that "VIP" is a bad idea, and I'm not pushing for
> it. I tabled it as something that might further this very same end:
> early and easy official recognition, to show trust and encourage
> contribution. We're really debating how high/low the committer bar
> should be, and if it's 'low', this idea does very little.

For solving the early and easy recognition problem, I've heard about people just saying "thank you" or making a "contributor of the month" honor.  That kind of recognition doesn't necessarily have to be in the form of a status.

But again, committership is more than a commit bit.  As an example, if you can make it easier for someone to attend ApacheCon who is doing good things for your project and is certain not to harm it, why wouldn't you do that?
 
> > I've seen this happen.  Especially when merges start slowing down, people either stop contributing altogether or just work from their own fork.  If you have enough "non-meriging" committers in your volunteer "pipeline" you have a better chance of people stepping up and becoming "merging" committers.  And at very least you remove a roadblock to participation when you make someone a committer.  Otherwise, you could accidentally doom your project to a lifespan equal to the volunteer burnout cycle of your one most dedicated volunteer.  Or accidentally couple it too tightly to the economic interests of that person's employer.  Either way, you'll shorten your project's lifespan unnecessarily.  And that would be a shame, because Spark is a really awesome project.
>
> On this I entirely agree. It's a different debate, but one we've had a
> lot over time: while there are possibly risks in adding someone as a
> committer, there are risks in not doing so too. You might find others
> on the PMC diverge more from your position, and I don't think it's a
> secret that I think the PMC has been a little overly conservative. The
> debate is reasonable (and visible on private@), and in-bounds w.r.t.
> The Apache Way. It needs to evolve, but, is not broken. I actually
> think members@ would do well to hear more in-bounds but diverging
> opinions, from good-faith and smart people from a different project.
> There are real, subtle questions here. A few people have gotten pretty
> dismissive of the learned experience of some large, successful ASF
> projects.

I agree here.  And I'm open to suggestions on how to help this conversation move.

Best Regards,
Myrle
 
Reply | Threaded
Open this post in threaded view
|

Re: Recognizing non-code contributions

Sean Owen-3
On Mon, Aug 5, 2019 at 3:50 AM Myrle Krantz <[hidden email]> wrote:
> So... events coordinators?  I'd still make them committers.  I guess I'm still struggling to understand what problem making people VIP's without giving them committership is trying to solve.

We may just agree to disagree, which is fine, but I think the argument
is clear enough: such a person has zero need for the commit bit.
Turning it around, what are we trying to accomplish by giving said
person a commit bit? I know people say there's no harm, but I think
there is at least _some_ downside. We're widening access to change
software artifacts, the main thing that we put ASF process and checks
around for liability reasons. I know the point is trust, and said
person is likely to understand to never use the commit bit, but it
brings us back to the same place. I don't wish to convince anyone else
of my stance, though I do find it more logical, just that it's
reasonable within The Apache Way.


> It also just occurred to me this morning: There are actually other privileges which go along with the "commit-bit" other than the ability to commit at will to the project's repos: people who are committers get an Apache e-mail address, and they get discounted entry to ApacheCon.  People who are committers also get added to our committers mailing list, and are thus a little easier to integrate into our foundation-wide efforts.
>
> To apply this to the example above, the Apache e-mail address can make it a tad easier for an event coordinator to conduct official business for a project.

Great points. Again if I'm making it up? a "VIP" should get an Apache
email address and discounts. Sure, why not put them on a committers@
list too for visibility.


> But that's not what I'm arguing.  I'm arguing that you can safely give commit access to anyone for whom you're reasonably certain they will do no harm.  And your certainty of that can actually be much higher with non-coding committers.  So if someone suggests a non-coding contributor for committer, it should be fairly easy to say "yes".  Especially if you're on a project like Spark where PMC ⊂ committers.

(Just to again be clear, we aren't talking only about 'non-coding'
committers. If it's shorthand for 'not contributing to docs/code in
the repo', we're on the same page.)
The case that started this is a corner case. The more interesting case
is, in fact, a docs-only contributor. That hasn't quite come up -- we
had a case of build- and config-only committer though. It's worth
keeping these arguments in mind for this more ambiguous hypothetical.
No objections in theory to making said person a committer, but in
practice it may be a harder case, possibly unnecessarily hard.

> For solving the early and easy recognition problem, I've heard about people just saying "thank you" or making a "contributor of the month" honor.  That kind of recognition doesn't necessarily have to be in the form of a status.

Sure, we do some of that on PRs, but probably need to do more. There
are some regular contributors doing good work, and I hope they feel
recognized by the fact they get more attention because of their track
record, but being explicit goes a long way.

---------------------------------------------------------------------
To unsubscribe e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Recognizing non-code contributions

Nicholas Chammas
On Mon, Aug 5, 2019 at 9:55 AM Sean Owen <[hidden email]> wrote:
On Mon, Aug 5, 2019 at 3:50 AM Myrle Krantz <[hidden email]> wrote:
> So... events coordinators?  I'd still make them committers.  I guess I'm still struggling to understand what problem making people VIP's without giving them committership is trying to solve.

We may just agree to disagree, which is fine, but I think the argument
is clear enough: such a person has zero need for the commit bit.
Turning it around, what are we trying to accomplish by giving said
person a commit bit? I know people say there's no harm, but I think
there is at least _some_ downside. We're widening access to change
software artifacts, the main thing that we put ASF process and checks
around for liability reasons. I know the point is trust, and said
person is likely to understand to never use the commit bit, but it
brings us back to the same place. I don't wish to convince anyone else
of my stance, though I do find it more logical, just that it's
reasonable within The Apache Way.

+1 to this.
Reply | Threaded
Open this post in threaded view
|

Re: Recognizing non-code contributions

Myrle Krantz
In reply to this post by Sean Owen-3
Hey Sean,

Even though we are discussing our differences, on the whole I don't think we're that far apart in our positions.  Still the differences are where the conversation is actually interesting, so here goes:

On Mon, Aug 5, 2019 at 3:55 PM Sean Owen <[hidden email]> wrote:
On Mon, Aug 5, 2019 at 3:50 AM Myrle Krantz <[hidden email]> wrote:
> So... events coordinators?  I'd still make them committers.  I guess I'm still struggling to understand what problem making people VIP's without giving them committership is trying to solve.

We may just agree to disagree, which is fine, but I think the argument
is clear enough: such a person has zero need for the commit bit.
Turning it around, what are we trying to accomplish by giving said
person a commit bit? I know people say there's no harm, but I think
there is at least _some_ downside. We're widening access to change
software artifacts, the main thing that we put ASF process and checks
around for liability reasons. I know the point is trust, and said
person is likely to understand to never use the commit bit, but it
brings us back to the same place. I don't wish to convince anyone else
of my stance, though I do find it more logical, just that it's
reasonable within The Apache Way.

We need to balance two sets of risks here.  But in the case of access to our software artifacts, the risk is very small, and already has *multiple* mitigating factors, from the fact that all changes are tracked to an individual, to the fact that there are notifications sent when changes are made, (and I'm going to stop listing the benefits of a modern source control system here, because I know you are aware of them), on through the fact that you have automated tests, and continuing through the fact that there is a release process during which artifacts get checked again.

If someone makes a commit who you are not expecting to make a commit, or in an area you weren't expecting changes in, you'll notice that, right?

What you're talking about here is your security model for your source repository.  But restricting access isn't really the right security model for an open source project.
 
> It also just occurred to me this morning: There are actually other privileges which go along with the "commit-bit" other than the ability to commit at will to the project's repos: people who are committers get an Apache e-mail address, and they get discounted entry to ApacheCon.  People who are committers also get added to our committers mailing list, and are thus a little easier to integrate into our foundation-wide efforts.
>
> To apply this to the example above, the Apache e-mail address can make it a tad easier for an event coordinator to conduct official business for a project.

Great points. Again if I'm making it up? a "VIP" should get an Apache
email address and discounts. Sure, why not put them on a committers@
list too for visibility.

In order to do that, you'd need to create this kind of in-between status Apache-wide.  I would be very much opposed to doing that for a couple of reasons:
* It adds complexity for infra and events with no clear benefits to the projects.
* The risk of creating a second-class status at the ASF is just too high for my comfort.
 
> But that's not what I'm arguing.  I'm arguing that you can safely give commit access to anyone for whom you're reasonably certain they will do no harm.  And your certainty of that can actually be much higher with non-coding committers.  So if someone suggests a non-coding contributor for committer, it should be fairly easy to say "yes".  Especially if you're on a project like Spark where PMC ⊂ committers.

(Just to again be clear, we aren't talking only about 'non-coding'
committers. If it's shorthand for 'not contributing to docs/code in
the repo', we're on the same page.)

Ack.  I actually think of documentation which goes into the repo as code, so I do think we're on the same page here.
 
The case that started this is a corner case. The more interesting case
is, in fact, a docs-only contributor. That hasn't quite come up -- we
had a case of build- and config-only committer though. It's worth
keeping these arguments in mind for this more ambiguous hypothetical.
No objections in theory to making said person a committer, but in
practice it may be a harder case, possibly unnecessarily hard.

Documents are IP.  You're better off if you have an ICLA for that stuff, regardless of where it lands in your project content.  And the most natural point in time to request an ICLA is at committer invitation.
 
> For solving the early and easy recognition problem, I've heard about people just saying "thank you" or making a "contributor of the month" honor.  That kind of recognition doesn't necessarily have to be in the form of a status.

Sure, we do some of that on PRs, but probably need to do more. There
are some regular contributors doing good work, and I hope they feel
recognized by the fact they get more attention because of their track
record, but being explicit goes a long way.

As they say: positive feedback to negative feedback ratio should be 7:1.  There are other parts of the foundation where we need to place more emphasis on positive feedback too.

Best,
Myrle 
Reply | Threaded
Open this post in threaded view
|

Re: Recognizing non-code contributions

Hyukjin Kwon
Myrle,

> We need to balance two sets of risks here.  But in the case of access to our software artifacts, the risk is very small, and already has *multiple* mitigating factors, from the fact that all changes are tracked to an individual, to the fact that there are notifications sent when changes are made, (and I'm going to stop listing the benefits of a modern source control system here, because I know you are aware of them), on through the fact that you have automated tests, and continuing through the fact that there is a release process during which artifacts get checked again.
> If someone makes a commit who you are not expecting to make a commit, or in an area you weren't expecting changes in, you'll notice that, right?
> What you're talking about here is your security model for your source repository.  But restricting access isn't really the right security model for an open source project.
 
I don't quite get the argument about commit bit. I _strongly_ disagree about "the risk is very small,".
Not all of committers track all the changes. There are so many changes in the upstream and it's already overhead to check all.
Do you know how many bugs Spark faces due to such lack of reviews that entirely blocks the release sometimes, and how much it takes time to fix up such commits?
We need expertise and familiarity to Spark.

It virtually means we will add some more overhead to audit each commit, even for committers'. Why should we bother add such overhead to harm the project?
To me, this is the most important fact. I don't think we should just count the number of positive and negative ones.

For other reasons, we can just add or discuss about the "this kind of in-between status Apache-wide", which is a bigger scope than here. You can ask it to ASF and discuss further.


2019년 8월 6일 (화) 오후 3:14, Myrle Krantz <[hidden email]>님이 작성:
Hey Sean,

Even though we are discussing our differences, on the whole I don't think we're that far apart in our positions.  Still the differences are where the conversation is actually interesting, so here goes:

On Mon, Aug 5, 2019 at 3:55 PM Sean Owen <[hidden email]> wrote:
On Mon, Aug 5, 2019 at 3:50 AM Myrle Krantz <[hidden email]> wrote:
> So... events coordinators?  I'd still make them committers.  I guess I'm still struggling to understand what problem making people VIP's without giving them committership is trying to solve.

We may just agree to disagree, which is fine, but I think the argument
is clear enough: such a person has zero need for the commit bit.
Turning it around, what are we trying to accomplish by giving said
person a commit bit? I know people say there's no harm, but I think
there is at least _some_ downside. We're widening access to change
software artifacts, the main thing that we put ASF process and checks
around for liability reasons. I know the point is trust, and said
person is likely to understand to never use the commit bit, but it
brings us back to the same place. I don't wish to convince anyone else
of my stance, though I do find it more logical, just that it's
reasonable within The Apache Way.

We need to balance two sets of risks here.  But in the case of access to our software artifacts, the risk is very small, and already has *multiple* mitigating factors, from the fact that all changes are tracked to an individual, to the fact that there are notifications sent when changes are made, (and I'm going to stop listing the benefits of a modern source control system here, because I know you are aware of them), on through the fact that you have automated tests, and continuing through the fact that there is a release process during which artifacts get checked again.

If someone makes a commit who you are not expecting to make a commit, or in an area you weren't expecting changes in, you'll notice that, right?

What you're talking about here is your security model for your source repository.  But restricting access isn't really the right security model for an open source project.
 
> It also just occurred to me this morning: There are actually other privileges which go along with the "commit-bit" other than the ability to commit at will to the project's repos: people who are committers get an Apache e-mail address, and they get discounted entry to ApacheCon.  People who are committers also get added to our committers mailing list, and are thus a little easier to integrate into our foundation-wide efforts.
>
> To apply this to the example above, the Apache e-mail address can make it a tad easier for an event coordinator to conduct official business for a project.

Great points. Again if I'm making it up? a "VIP" should get an Apache
email address and discounts. Sure, why not put them on a committers@
list too for visibility.

In order to do that, you'd need to create this kind of in-between status Apache-wide.  I would be very much opposed to doing that for a couple of reasons:
* It adds complexity for infra and events with no clear benefits to the projects.
* The risk of creating a second-class status at the ASF is just too high for my comfort.
 
> But that's not what I'm arguing.  I'm arguing that you can safely give commit access to anyone for whom you're reasonably certain they will do no harm.  And your certainty of that can actually be much higher with non-coding committers.  So if someone suggests a non-coding contributor for committer, it should be fairly easy to say "yes".  Especially if you're on a project like Spark where PMC ⊂ committers.

(Just to again be clear, we aren't talking only about 'non-coding'
committers. If it's shorthand for 'not contributing to docs/code in
the repo', we're on the same page.)

Ack.  I actually think of documentation which goes into the repo as code, so I do think we're on the same page here.
 
The case that started this is a corner case. The more interesting case
is, in fact, a docs-only contributor. That hasn't quite come up -- we
had a case of build- and config-only committer though. It's worth
keeping these arguments in mind for this more ambiguous hypothetical.
No objections in theory to making said person a committer, but in
practice it may be a harder case, possibly unnecessarily hard.

Documents are IP.  You're better off if you have an ICLA for that stuff, regardless of where it lands in your project content.  And the most natural point in time to request an ICLA is at committer invitation.
 
> For solving the early and easy recognition problem, I've heard about people just saying "thank you" or making a "contributor of the month" honor.  That kind of recognition doesn't necessarily have to be in the form of a status.

Sure, we do some of that on PRs, but probably need to do more. There
are some regular contributors doing good work, and I hope they feel
recognized by the fact they get more attention because of their track
record, but being explicit goes a long way.

As they say: positive feedback to negative feedback ratio should be 7:1.  There are other parts of the foundation where we need to place more emphasis on positive feedback too.

Best,
Myrle 
Reply | Threaded
Open this post in threaded view
|

Re: Recognizing non-code contributions

Hyukjin Kwon
So, here's my thought:

1. Back to the original point, for recognition of such people, I think we can simply list up such people in Spark Website somewhere. For instance,

  Person A: Spark Book
  Person B: Meetup leader

I don't know if ASF allows this. Someone needs to check it.


2. If we need the in-between status officially (e.g. Apache email or something), it should be asked and discussed in ASF, not in a single project here.


2019년 8월 6일 (화) 오후 4:55, Hyukjin Kwon <[hidden email]>님이 작성:
Myrle,

> We need to balance two sets of risks here.  But in the case of access to our software artifacts, the risk is very small, and already has *multiple* mitigating factors, from the fact that all changes are tracked to an individual, to the fact that there are notifications sent when changes are made, (and I'm going to stop listing the benefits of a modern source control system here, because I know you are aware of them), on through the fact that you have automated tests, and continuing through the fact that there is a release process during which artifacts get checked again.
> If someone makes a commit who you are not expecting to make a commit, or in an area you weren't expecting changes in, you'll notice that, right?
> What you're talking about here is your security model for your source repository.  But restricting access isn't really the right security model for an open source project.
 
I don't quite get the argument about commit bit. I _strongly_ disagree about "the risk is very small,".
Not all of committers track all the changes. There are so many changes in the upstream and it's already overhead to check all.
Do you know how many bugs Spark faces due to such lack of reviews that entirely blocks the release sometimes, and how much it takes time to fix up such commits?
We need expertise and familiarity to Spark.

It virtually means we will add some more overhead to audit each commit, even for committers'. Why should we bother add such overhead to harm the project?
To me, this is the most important fact. I don't think we should just count the number of positive and negative ones.

For other reasons, we can just add or discuss about the "this kind of in-between status Apache-wide", which is a bigger scope than here. You can ask it to ASF and discuss further.


2019년 8월 6일 (화) 오후 3:14, Myrle Krantz <[hidden email]>님이 작성:
Hey Sean,

Even though we are discussing our differences, on the whole I don't think we're that far apart in our positions.  Still the differences are where the conversation is actually interesting, so here goes:

On Mon, Aug 5, 2019 at 3:55 PM Sean Owen <[hidden email]> wrote:
On Mon, Aug 5, 2019 at 3:50 AM Myrle Krantz <[hidden email]> wrote:
> So... events coordinators?  I'd still make them committers.  I guess I'm still struggling to understand what problem making people VIP's without giving them committership is trying to solve.

We may just agree to disagree, which is fine, but I think the argument
is clear enough: such a person has zero need for the commit bit.
Turning it around, what are we trying to accomplish by giving said
person a commit bit? I know people say there's no harm, but I think
there is at least _some_ downside. We're widening access to change
software artifacts, the main thing that we put ASF process and checks
around for liability reasons. I know the point is trust, and said
person is likely to understand to never use the commit bit, but it
brings us back to the same place. I don't wish to convince anyone else
of my stance, though I do find it more logical, just that it's
reasonable within The Apache Way.

We need to balance two sets of risks here.  But in the case of access to our software artifacts, the risk is very small, and already has *multiple* mitigating factors, from the fact that all changes are tracked to an individual, to the fact that there are notifications sent when changes are made, (and I'm going to stop listing the benefits of a modern source control system here, because I know you are aware of them), on through the fact that you have automated tests, and continuing through the fact that there is a release process during which artifacts get checked again.

If someone makes a commit who you are not expecting to make a commit, or in an area you weren't expecting changes in, you'll notice that, right?

What you're talking about here is your security model for your source repository.  But restricting access isn't really the right security model for an open source project.
 
> It also just occurred to me this morning: There are actually other privileges which go along with the "commit-bit" other than the ability to commit at will to the project's repos: people who are committers get an Apache e-mail address, and they get discounted entry to ApacheCon.  People who are committers also get added to our committers mailing list, and are thus a little easier to integrate into our foundation-wide efforts.
>
> To apply this to the example above, the Apache e-mail address can make it a tad easier for an event coordinator to conduct official business for a project.

Great points. Again if I'm making it up? a "VIP" should get an Apache
email address and discounts. Sure, why not put them on a committers@
list too for visibility.

In order to do that, you'd need to create this kind of in-between status Apache-wide.  I would be very much opposed to doing that for a couple of reasons:
* It adds complexity for infra and events with no clear benefits to the projects.
* The risk of creating a second-class status at the ASF is just too high for my comfort.
 
> But that's not what I'm arguing.  I'm arguing that you can safely give commit access to anyone for whom you're reasonably certain they will do no harm.  And your certainty of that can actually be much higher with non-coding committers.  So if someone suggests a non-coding contributor for committer, it should be fairly easy to say "yes".  Especially if you're on a project like Spark where PMC ⊂ committers.

(Just to again be clear, we aren't talking only about 'non-coding'
committers. If it's shorthand for 'not contributing to docs/code in
the repo', we're on the same page.)

Ack.  I actually think of documentation which goes into the repo as code, so I do think we're on the same page here.
 
The case that started this is a corner case. The more interesting case
is, in fact, a docs-only contributor. That hasn't quite come up -- we
had a case of build- and config-only committer though. It's worth
keeping these arguments in mind for this more ambiguous hypothetical.
No objections in theory to making said person a committer, but in
practice it may be a harder case, possibly unnecessarily hard.

Documents are IP.  You're better off if you have an ICLA for that stuff, regardless of where it lands in your project content.  And the most natural point in time to request an ICLA is at committer invitation.
 
> For solving the early and easy recognition problem, I've heard about people just saying "thank you" or making a "contributor of the month" honor.  That kind of recognition doesn't necessarily have to be in the form of a status.

Sure, we do some of that on PRs, but probably need to do more. There
are some regular contributors doing good work, and I hope they feel
recognized by the fact they get more attention because of their track
record, but being explicit goes a long way.

As they say: positive feedback to negative feedback ratio should be 7:1.  There are other parts of the foundation where we need to place more emphasis on positive feedback too.

Best,
Myrle 
Reply | Threaded
Open this post in threaded view
|

Re: Recognizing non-code contributions

Myrle Krantz
In reply to this post by Hyukjin Kwon
Hey Hyukjin,

Apologies for sending this to you twice.  : o)

On Tue, Aug 6, 2019 at 9:55 AM Hyukjin Kwon <[hidden email]> wrote:
Myrle,

> We need to balance two sets of risks here.  But in the case of access to our software artifacts, the risk is very small, and already has *multiple* mitigating factors, from the fact that all changes are tracked to an individual, to the fact that there are notifications sent when changes are made, (and I'm going to stop listing the benefits of a modern source control system here, because I know you are aware of them), on through the fact that you have automated tests, and continuing through the fact that there is a release process during which artifacts get checked again.
> If someone makes a commit who you are not expecting to make a commit, or in an area you weren't expecting changes in, you'll notice that, right?
> What you're talking about here is your security model for your source repository.  But restricting access isn't really the right security model for an open source project.
 
I don't quite get the argument about commit bit. I _strongly_ disagree about "the risk is very small,".
Not all of committers track all the changes. There are so many changes in the upstream and it's already overhead to check all.
Do you know how many bugs Spark faces due to such lack of reviews that entirely blocks the release sometimes, and how much it takes time to fix up such commits?
We need expertise and familiarity to Spark.

Let's unroll that a bit.  Say that you invite a non-coding contributor to be a committer.  To make an inappropriate commit two things would have to happen: this person would have to decide to make the commit, and this person would have to set up access to the git repository, either by enabling gitbox integration, or accessing the apache git repository directly.  Before you invite them you make an estimation of the probability that they would do the first: that is decide to make an inappropriate commit.  You decide that that is fairly unlikely.  But for a non-coding contributor the chances of them actually going through the mechanics of making a commit is even more unlikely.  I think we can safely assume that the chance of someone who you've determined is committed to the community and knows their limits of doing this is simply 00.00%.

That leaves the question of what the chance is that this person will leak their credentials to a malicious third party intent on introducing bugs into Spark code.  Do you believe there are such malicious third parties?  How many attacks have there been on Spark committer credentials?  I believe the likelihood of this happening is 00.00% (but I am willing to be swayed by evidence otherwise -- should probably be discussed on the private@ list though if it's out there.: o).

But let's say I'm wrong about both of those probabilities.  Let's say the combined probability of one of those two things happening is actually 0.01%.  This is where the advantages of modern source control and tests come in.  Even if there's only a 50% chance that watching commits will catch the error, and only a further 50% chance that tests will catch the error, and only a further 50% chance that the error will be caught in release testing, those chances multiply out at 00.00125%.

Based on those guestimates the risk is somewhere between 00.00% and 00.00125%.  The risk is very small.  You take bigger risks every day in order to move your project forward.
 
It virtually means we will add some more overhead to audit each commit, even for committers'. Why should we bother add such overhead to harm the project?
To me, this is the most important fact. I don't think we should just count the number of positive and negative ones.

Based on this argumentation you will never invite any committers or even merge any pull requests.

But you do invite committers and you do merge pull requests because it's good for your project.  Because the risk of doing nothing is greater.
 
For other reasons, we can just add or discuss about the "this kind of in-between status Apache-wide", which is a bigger scope than here. You can ask it to ASF and discuss further.

I can say with considerable confidence: There will be no "in-between" status Apache-wide.  But if you disagree, and want to start a discussion to suggest that, [hidden email] is a good place to go with it.

Best Regards,
Myrle
Reply | Threaded
Open this post in threaded view
|

Re: Recognizing non-code contributions

Hyukjin Kwon
I usually make such judgement about commit bit based upon community activity in coding and reviewing.
If somebody has no activity about those commit bits, I would have no way to know about this guy,
Simply I can't make a judgement about coding activity based upon non-coding activity.

Those bugs and commit stuff are pretty critical in this project as I described. I would rather try to decrease such
possibility, not increase it even when such "commit bit" is unnecessary.

We have found and discussed nicer other ways to recognise them, for instance, listing them in somewhere else in Spark website.
Once they are in that list, I suspect it's easier and closer to the committership to, say, get an Apache email if it matters.

Shall we avoid such possibilities at all and go for such other safer ways?
I think you also accept commit bit is unnecessary in this case.
So, we don't unnecessarily give it to them, which is anyhow critical in this project.

> Based on this argumentation you will never invite any committers or even merge any pull requests.
BTW, how did you reach that conclusion? I want somebody who can review PRs and fix such bugs, rather than who has more possibility to make such mistakes.


2019년 8월 6일 (화) 오후 7:26, Myrle Krantz <[hidden email]>님이 작성:
Hey Hyukjin,

Apologies for sending this to you twice.  : o)

On Tue, Aug 6, 2019 at 9:55 AM Hyukjin Kwon <[hidden email]> wrote:
Myrle,

> We need to balance two sets of risks here.  But in the case of access to our software artifacts, the risk is very small, and already has *multiple* mitigating factors, from the fact that all changes are tracked to an individual, to the fact that there are notifications sent when changes are made, (and I'm going to stop listing the benefits of a modern source control system here, because I know you are aware of them), on through the fact that you have automated tests, and continuing through the fact that there is a release process during which artifacts get checked again.
> If someone makes a commit who you are not expecting to make a commit, or in an area you weren't expecting changes in, you'll notice that, right?
> What you're talking about here is your security model for your source repository.  But restricting access isn't really the right security model for an open source project.
 
I don't quite get the argument about commit bit. I _strongly_ disagree about "the risk is very small,".
Not all of committers track all the changes. There are so many changes in the upstream and it's already overhead to check all.
Do you know how many bugs Spark faces due to such lack of reviews that entirely blocks the release sometimes, and how much it takes time to fix up such commits?
We need expertise and familiarity to Spark.

Let's unroll that a bit.  Say that you invite a non-coding contributor to be a committer.  To make an inappropriate commit two things would have to happen: this person would have to decide to make the commit, and this person would have to set up access to the git repository, either by enabling gitbox integration, or accessing the apache git repository directly.  Before you invite them you make an estimation of the probability that they would do the first: that is decide to make an inappropriate commit.  You decide that that is fairly unlikely.  But for a non-coding contributor the chances of them actually going through the mechanics of making a commit is even more unlikely.  I think we can safely assume that the chance of someone who you've determined is committed to the community and knows their limits of doing this is simply 00.00%.

That leaves the question of what the chance is that this person will leak their credentials to a malicious third party intent on introducing bugs into Spark code.  Do you believe there are such malicious third parties?  How many attacks have there been on Spark committer credentials?  I believe the likelihood of this happening is 00.00% (but I am willing to be swayed by evidence otherwise -- should probably be discussed on the private@ list though if it's out there.: o).

But let's say I'm wrong about both of those probabilities.  Let's say the combined probability of one of those two things happening is actually 0.01%.  This is where the advantages of modern source control and tests come in.  Even if there's only a 50% chance that watching commits will catch the error, and only a further 50% chance that tests will catch the error, and only a further 50% chance that the error will be caught in release testing, those chances multiply out at 00.00125%.

Based on those guestimates the risk is somewhere between 00.00% and 00.00125%.  The risk is very small.  You take bigger risks every day in order to move your project forward.
 
It virtually means we will add some more overhead to audit each commit, even for committers'. Why should we bother add such overhead to harm the project?
To me, this is the most important fact. I don't think we should just count the number of positive and negative ones.

Based on this argumentation you will never invite any committers or even merge any pull requests.

But you do invite committers and you do merge pull requests because it's good for your project.  Because the risk of doing nothing is greater.
 
For other reasons, we can just add or discuss about the "this kind of in-between status Apache-wide", which is a bigger scope than here. You can ask it to ASF and discuss further.

I can say with considerable confidence: There will be no "in-between" status Apache-wide.  But if you disagree, and want to start a discussion to suggest that, [hidden email] is a good place to go with it.

Best Regards,
Myrle
Reply | Threaded
Open this post in threaded view
|

Re: Recognizing non-code contributions

Jungtaek Lim
My 2 cents as just one of contributors of Apache Spark project.

The thing is, what's the merit for both contributors and PMC members on granting committership on non-code contributors. I'd rather say someone is a good candidate to be invited as a committer to co-maintain a part of code repository if non-code contributions (like documentation) have been happening on code repository. Assuming we're granting committership to major contributors on documentation, they would maintain the doc area only unless they're having confident on the area what they are reviewing. In many cases, major contributions on documentation often requires major "technical aspect" of understanding the project (I guess we're not saying about fixing typos) which would also represent the knowledge on that area.

On the other side, if we are talking about non-code contributors who contributes "outside" of repository, I'd say there's less (even no) merits to grant committership. In such case, granting write privilege doesn't help these contributors to make their contributions easier. No merits on PMC members as well. For me, the origin meaning of "committership" is just a "write privilege on repository". While there're more role and responsibility as well as more merits on committership in ASF, I'd rather think again what's the real value if the reason of granting committership doesn't apply to the origin meaning.

If we would like to use "committership" as a recognition on major contributions for the project in any way, I'd love to see some other approach (like VIP? actually not sure what it meant in previous mail) to do so. Let's focus on origin meaning of "committership", and not couple with providing apache email address or giving chance to get various merits what ASF committers have been enjoying. I hope there's other way to provide these merits while we don't grant "unnecessary" privilege.

-Jungtaek Lim (HeartSaVioR)


On Tue, Aug 6, 2019 at 10:08 PM Hyukjin Kwon <[hidden email]> wrote:
I usually make such judgement about commit bit based upon community activity in coding and reviewing.
If somebody has no activity about those commit bits, I would have no way to know about this guy,
Simply I can't make a judgement about coding activity based upon non-coding activity.

Those bugs and commit stuff are pretty critical in this project as I described. I would rather try to decrease such
possibility, not increase it even when such "commit bit" is unnecessary.

We have found and discussed nicer other ways to recognise them, for instance, listing them in somewhere else in Spark website.
Once they are in that list, I suspect it's easier and closer to the committership to, say, get an Apache email if it matters.

Shall we avoid such possibilities at all and go for such other safer ways?
I think you also accept commit bit is unnecessary in this case.
So, we don't unnecessarily give it to them, which is anyhow critical in this project.

> Based on this argumentation you will never invite any committers or even merge any pull requests.
BTW, how did you reach that conclusion? I want somebody who can review PRs and fix such bugs, rather than who has more possibility to make such mistakes.


2019년 8월 6일 (화) 오후 7:26, Myrle Krantz <[hidden email]>님이 작성:
Hey Hyukjin,

Apologies for sending this to you twice.  : o)

On Tue, Aug 6, 2019 at 9:55 AM Hyukjin Kwon <[hidden email]> wrote:
Myrle,

> We need to balance two sets of risks here.  But in the case of access to our software artifacts, the risk is very small, and already has *multiple* mitigating factors, from the fact that all changes are tracked to an individual, to the fact that there are notifications sent when changes are made, (and I'm going to stop listing the benefits of a modern source control system here, because I know you are aware of them), on through the fact that you have automated tests, and continuing through the fact that there is a release process during which artifacts get checked again.
> If someone makes a commit who you are not expecting to make a commit, or in an area you weren't expecting changes in, you'll notice that, right?
> What you're talking about here is your security model for your source repository.  But restricting access isn't really the right security model for an open source project.
 
I don't quite get the argument about commit bit. I _strongly_ disagree about "the risk is very small,".
Not all of committers track all the changes. There are so many changes in the upstream and it's already overhead to check all.
Do you know how many bugs Spark faces due to such lack of reviews that entirely blocks the release sometimes, and how much it takes time to fix up such commits?
We need expertise and familiarity to Spark.

Let's unroll that a bit.  Say that you invite a non-coding contributor to be a committer.  To make an inappropriate commit two things would have to happen: this person would have to decide to make the commit, and this person would have to set up access to the git repository, either by enabling gitbox integration, or accessing the apache git repository directly.  Before you invite them you make an estimation of the probability that they would do the first: that is decide to make an inappropriate commit.  You decide that that is fairly unlikely.  But for a non-coding contributor the chances of them actually going through the mechanics of making a commit is even more unlikely.  I think we can safely assume that the chance of someone who you've determined is committed to the community and knows their limits of doing this is simply 00.00%.

That leaves the question of what the chance is that this person will leak their credentials to a malicious third party intent on introducing bugs into Spark code.  Do you believe there are such malicious third parties?  How many attacks have there been on Spark committer credentials?  I believe the likelihood of this happening is 00.00% (but I am willing to be swayed by evidence otherwise -- should probably be discussed on the private@ list though if it's out there.: o).

But let's say I'm wrong about both of those probabilities.  Let's say the combined probability of one of those two things happening is actually 0.01%.  This is where the advantages of modern source control and tests come in.  Even if there's only a 50% chance that watching commits will catch the error, and only a further 50% chance that tests will catch the error, and only a further 50% chance that the error will be caught in release testing, those chances multiply out at 00.00125%.

Based on those guestimates the risk is somewhere between 00.00% and 00.00125%.  The risk is very small.  You take bigger risks every day in order to move your project forward.
 
It virtually means we will add some more overhead to audit each commit, even for committers'. Why should we bother add such overhead to harm the project?
To me, this is the most important fact. I don't think we should just count the number of positive and negative ones.

Based on this argumentation you will never invite any committers or even merge any pull requests.

But you do invite committers and you do merge pull requests because it's good for your project.  Because the risk of doing nothing is greater.
 
For other reasons, we can just add or discuss about the "this kind of in-between status Apache-wide", which is a bigger scope than here. You can ask it to ASF and discuss further.

I can say with considerable confidence: There will be no "in-between" status Apache-wide.  But if you disagree, and want to start a discussion to suggest that, [hidden email] is a good place to go with it.

Best Regards,
Myrle


--
Reply | Threaded
Open this post in threaded view
|

Re: Recognizing non-code contributions

Sean Owen-3
In reply to this post by Myrle Krantz
On Tue, Aug 6, 2019 at 1:14 AM Myrle Krantz <[hidden email]> wrote:
> If someone makes a commit who you are not expecting to make a commit, or in an area you weren't expecting changes in, you'll notice that, right?

Not counterarguments, but just more color on the hesitation:

- Probably, but it's less obvious on a big project than a small one!
- More likely: person commits in an area they know, and it breaks
something elsewhere unexpectedly. Tests can catch most but not all of
this. That's a risk everywhere though.
- Or: most commits aren't _authored_ by committers here (I think?) but
_merged_ by committers. It's still possible to watch for this, but
harder.
- It's harder to retroactively review commits and revert if needed,
not impossible

Honestly I think most of Spark is run with the attitude you describe.
It's the core and SQL modules that generate the worry, because
correctness and semantics are much more sensitive there.

I know at one time we tried the notion of 'maintainers' for areas of
the code, where it was strongly suggested that a change to module X be
reviewed by one of a few experts on that part of the code. It was
never really enforced and so dropped. I recall it was a little
controversial at the time: why are you trying to create committers
with more/less power over the code? Yet I think that's the substance
of the 'what harm can it do?' argument: just make sure committers
stick to their appropriate area and then there's really no worry.


> In order to do that, you'd need to create this kind of in-between status Apache-wide.  I would be very much opposed to doing that for a couple of reasons:
> * It adds complexity for infra and events with no clear benefits to the projects.
> * The risk of creating a second-class status at the ASF is just too high for my comfort.

This is a good practical argument. I'd still push back on the idea
that there is no benefit (cf. supra), but it may not be worth the
headache or simple admin overhead.
I don't buy the second-class citizen argument so much. We already have
a board, PMC, committer statuses. It's just that we're used to these
tiers.
I don't think you're being dogmatic about it, but, some are, some of
the same people railing against squashing new ideas because they're
different!


> Documents are IP.  You're better off if you have an ICLA for that stuff, regardless of where it lands in your project content.  And the most natural point in time to request an ICLA is at committer invitation.

Side point: ICLAs are always nice-to-have but not required, no? most
contributions don't come from those with an ICLA nor would we want to
block contributions on signing one. It's just orthogonal. I take your
point that a regular contributor probably should sign an ICLA, and a
regular contributor should be a committer, just not that they should
be a committer because they should sign an ICLA.


You can tell there's a range of opinions here. I'm probably less
'conservative' about adding committers than most on the PMC, right or
wrong, but more conservative than some at the ASF. I think there's
room to inch towards the middle ground here and this is good
discussion informing the thinking.

---------------------------------------------------------------------
To unsubscribe e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Recognizing non-code contributions

Myrle Krantz


On Tue, Aug 6, 2019 at 5:36 PM Sean Owen <[hidden email]> wrote:
You can tell there's a range of opinions here. I'm probably less
'conservative' about adding committers than most on the PMC, right or
wrong, but more conservative than some at the ASF. I think there's
room to inch towards the middle ground here and this is good
discussion informing the thinking.

That's not actually my current reading of the Spark community.  My current reading based on the responses of Hyukjin, and Jungtaek, is that your community wouldn't take a non-coding committer no matter how clear their contributions are to the community, and that by extension such a person could never become a PMC member.

If my reading is correct (and the sample size *is* still quite small, and only includes one PMC member), I see that as a serious problem.

How do the other PMC members and community members see this?

Best Regards,
Myrle
Reply | Threaded
Open this post in threaded view
|

Re: Recognizing non-code contributions

Holden Karau
So I’d like to add non-coding committers, I think there is great value in both recognizing them and eventually having a broader PMC (eg maybe someone who’s put a lot of time into teaching Spark has important things to say about a proposed release, perhaps important enough for a binding vote).

That being said I think that my view is not aligned with the rest of the PMC and I believe it is important that we work together so I’m ok with exploring things like Spark VIP (I think in Kafka land there is an MVP of the year concept but I need to talk with folks over there more for ideas on how they run it).

I like to think the Apache way is broad enough to allow for variations like this to be explored in different projects while sharing what has worked and not worked historically so that we can all build healthy OSS communities.

On Tue, Aug 6, 2019 at 8:46 AM Myrle Krantz <[hidden email]> wrote:


On Tue, Aug 6, 2019 at 5:36 PM Sean Owen <[hidden email]> wrote:
You can tell there's a range of opinions here. I'm probably less
'conservative' about adding committers than most on the PMC, right or
wrong, but more conservative than some at the ASF. I think there's
room to inch towards the middle ground here and this is good
discussion informing the thinking.

That's not actually my current reading of the Spark community.  My current reading based on the responses of Hyukjin, and Jungtaek, is that your community wouldn't take a non-coding committer no matter how clear their contributions are to the community, and that by extension such a person could never become a PMC member.

If my reading is correct (and the sample size *is* still quite small, and only includes one PMC member), I see that as a serious problem.

How do the other PMC members and community members see this?

Best Regards,
Myrle
--
Books (Learning Spark, High Performance Spark, etc.): https://amzn.to/2MaRAG9 
Reply | Threaded
Open this post in threaded view
|

Re: Recognizing non-code contributions

Hyukjin Kwon
In reply to this post by Myrle Krantz
Well, actually I am rather less conservative on adding committers. There are multiple people who are active in both non-coding and coding activities.
I as an example am one of Korean meetup admin and my main focus was to management JIRA. In addition, review the PRs that are not being reviewed.
As I said earlier at the very first time, I think committers should ideally be used to the dev at some degrees as primary. Other contributions should be counted.

I wonder which project nominees non-coding only committers but I at least know multiple projects. They all have that serious problem then.

2019년 8월 7일 (수) 오전 12:46, Myrle Krantz <[hidden email]>님이 작성:


On Tue, Aug 6, 2019 at 5:36 PM Sean Owen <[hidden email]> wrote:
You can tell there's a range of opinions here. I'm probably less
'conservative' about adding committers than most on the PMC, right or
wrong, but more conservative than some at the ASF. I think there's
room to inch towards the middle ground here and this is good
discussion informing the thinking.

That's not actually my current reading of the Spark community.  My current reading based on the responses of Hyukjin, and Jungtaek, is that your community wouldn't take a non-coding committer no matter how clear their contributions are to the community, and that by extension such a person could never become a PMC member.

If my reading is correct (and the sample size *is* still quite small, and only includes one PMC member), I see that as a serious problem.

How do the other PMC members and community members see this?

Best Regards,
Myrle
Reply | Threaded
Open this post in threaded view
|

Re: Recognizing non-code contributions

Hyukjin Kwon
> I wonder which project nominees non-coding only committers but I at least know multiple projects. They all have that serious problem then.

I mean It know multiple projects don't do that and according to what you said, they all have that serious problem.

2019년 8월 7일 (수) 오전 1:05, Hyukjin Kwon <[hidden email]>님이 작성:
Well, actually I am rather less conservative on adding committers. There are multiple people who are active in both non-coding and coding activities.
I as an example am one of Korean meetup admin and my main focus was to management JIRA. In addition, review the PRs that are not being reviewed.
As I said earlier at the very first time, I think committers should ideally be used to the dev at some degrees as primary. Other contributions should be counted.

I wonder which project nominees non-coding only committers but I at least know multiple projects. They all have that serious problem then.

2019년 8월 7일 (수) 오전 12:46, Myrle Krantz <[hidden email]>님이 작성:


On Tue, Aug 6, 2019 at 5:36 PM Sean Owen <[hidden email]> wrote:
You can tell there's a range of opinions here. I'm probably less
'conservative' about adding committers than most on the PMC, right or
wrong, but more conservative than some at the ASF. I think there's
room to inch towards the middle ground here and this is good
discussion informing the thinking.

That's not actually my current reading of the Spark community.  My current reading based on the responses of Hyukjin, and Jungtaek, is that your community wouldn't take a non-coding committer no matter how clear their contributions are to the community, and that by extension such a person could never become a PMC member.

If my reading is correct (and the sample size *is* still quite small, and only includes one PMC member), I see that as a serious problem.

How do the other PMC members and community members see this?

Best Regards,
Myrle
12