On Sun, Nov 13, 2016 at 1:13 AM, Ben Slater <ben.sla...@instaclustr.com> wrote: > For anyone that’s interested, I’ve submitted my doc changes for point 2 > below (emphasising contributions other than new features) here: > https://issues.apache.org/jira/browse/CASSANDRA-12906 > > I haven’t added anything about the sponsor/shepherd idea as doesn’t seem to > be agreed at this point. > > Cheers > Ben > > On Mon, 7 Nov 2016 at 09:34 Nate McCall <zznat...@gmail.com> wrote: > >> Ben, >> Thank you for providing two thoughtful, concrete recommendations. >> There is some good feedback in general on this thread, but I'm calling >> Ben's response out because point #1 is important to discuss and point >> #2 is immediately actionable. >> >> > 1) I think some process of assigning a committer of a “sponsor” of a >> change >> > (which would probably mean committers volunteering) before it commences >> > would be useful. You can kind of do this at the moment by creating a JIRA >> > and asking for comment but I think the process is a bit unclear and a bit >> > intimidating for people starting off and it would be nice to know who was >> > your primary reviewer for a piece of work. (Or maybe this process does >> > exist and I don’t know about.) >> >> This is a good idea, but it assumes a single point triage and resource >> management that we don't really have right now. >> >> For the history of the project, we had triage in the form of sponsored >> resources flighting most of the new issues. This has made the rest of >> us complacent. It's probably the most immediate thing to fix and I >> don't know how to do that. >> >> Does anybody have any recommendations about ASF projects doing this >> effectively? Note that the folks from DS engineering are still heavily >> involved and I very much thank them for that, but diversifying is the >> only way to get us over our complacency. >> >> > 2) I think the “how to contribute” docs could emphasise activities other >> > than creating new features as a great place to start.It seems that >> review, >> > testing and doco could all do with more hands (as on just about any >> > project). So, encouraging this as a way to start on the project might >> help >> > to get some more bandwidth in this area rather than people creating >> patches >> > that the committers don’t have bandwidth to review. I would be happy to >> > draft an update to the docs including some of this if people think it’s a >> > good idea. >> >> Also a good idea and much more accessible/easily fixable. >> >> We will gladly look at any doc updates for this, looping in the >> broader community once published (this last part being key - I'm >> afraid if we ask for help too early, we'll get tons of interest to >> which we cannot reply and then be in even worse shape). >> >> -Nate >>
-- Eric Evans john.eric.ev...@gmail.com
