(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 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 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 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 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 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 님이 작성:
>
> 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: dev-unsubscr...@spark.apache.org
