(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 <matei.zaha...@gmail.com> 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 <r...@databricks.com> 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 <cloud0...@gmail.com> 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 <felixche...@apache.org> 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 <gurwls...@gmail.com> 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 <sro...@apache.org>님이 작성: >>>>> >>>>> 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
