We could require ASF JIRA accounts, but it will definitely keep some people from contributing. We have no way to measure what the fall off is because we won't be able to tell those folks apart from those who don't follow up on the PR for other reasons.
We can't automate closing PRs because the only way to close a PR is by pushing a commit to our master branch and ASF policy doesn't allow for non-commiters pushing into the repository if the repository is used to make release artifacts. This needn't be a pressing issue. We've had 90 PRs _ever_, so right now we're only talking about ~2 per month. On Mon, Sep 3, 2018 at 1:26 PM Misty Linville <[email protected]> wrote: > > I like this suggestion, Yu, along with enthusiastic closing of GitHub PRs > that don't follow the established procedures. Could we create an automated > test for such compliance, like scanning the PR comments for specific text? > CNCF projects use automation to parse a specific syntax in comments and set > GitHub labels based on it. It could be as simple as /jira HBASE-foo, and > automation could check that the issue actually exists and is open. The PR > author could get a grace period of say a week before the PR is > automatically closed, with warnings at regular intervals. Even if the PR is > closed they can easily reopen it when they have created the issue. If they > don't, we can't take their contribution, no matter how good it is. > > This approach front-loads the work of creating the automation, but reduces > overall load of reviewers verifying compliance of the PR. It also enforces > the policy with more consistency than relying on humans to do it. > > I suspect that ASF will eventually need to offer account holders to > associate their account with a GitHub account, and that would alleviate > some of this. There could even be a chain of trust by committing a > cryptographically unique file generated by ASF processes into the user's > GitHub account maybe (as a gist?) as part of that connection, or by using > GitHub's authorization system. > > On Sun, Sep 2, 2018, 11:32 PM Yu Li <[email protected]> wrote: > > > Maybe we could follow some other projects' process? For example I could > > find below lines of Flink's Code of Conduct > > <https://flink.apache.org/contribute-code.html>, JFYI: > > > > *Before you start coding…* > > > > *…please make sure there is a Jira issue that corresponds to your > > contribution. This is a general rule that the Flink community follows for > > all code contributions, including bug fixes, improvements, or new features, > > with an exception for trivial hot fixes. If you would like to fix a bug > > that you found or if you would like to add a new feature or improvement to > > Flink, please follow the File a bug report > > <https://flink.apache.org/how-to-contribute.html#file-a-bug-report> or > > Propose > > an improvement or a new feature > > < > > https://flink.apache.org/how-to-contribute.html#propose-an-improvement-or-a-new-feature > > > > > guidelines > > to open an issue in Flink’s Jira > > <http://issues.apache.org/jira/browse/FLINK> before starting with the > > implementation.* > > > > Best Regards, > > Yu > > > > > > On Mon, 3 Sep 2018 at 00:52, Andrew Purtell <[email protected]> > > wrote: > > > > > It's on us as committers to ensure Apache policies on code contribution > > > are followed. I think that is the bottom line. Our identities are known > > to > > > Apache infrastructure and recorded in commit history. By committing we > > are > > > asserting we believe the provenance of the contribution is known and > > > conforms to Apache policy. If you have concerns then don't commit. > > > Otherwise, it is the same as it always was. Both of Apache's JIRA > > instance > > > and Github offer self service account signups without any sort of > > identity > > > verification, only verification that the email account provided is valid > > > and under the control of the contributor. > > > > > > I think opening placeholder JIRAs as committers because we need it for > > > tracking is fine. With my PMC hat on I'd like to wonder aloud what is the > > > problem with signing up to Apache's JIRA instance. Any reason to be > > > concerned? I take it you don't think so. I also take it you believe you > > > know the identity of the contributor. Assuming you answer in the > > > affirmative I don't see that we have any issues. > > > > > > > > > > On Sep 2, 2018, at 9:00 AM, Sean Busbey <[email protected]> wrote: > > > > > > > >> On Mon, Aug 20, 2018, 22:09 Stack <[email protected]> wrote: > > > >> > > > >> This came up at the recent devs meeting: could we move to github flow > > > >> committing to Apache HBase? Do folks want this? If so, what would it > > > take? > > > >> What would it look like? > > > >> > > > >> The new gitbox repos at apache allow contribution back into apache via > > > >> github tooling: PRs can be merged into apache repos with a click of a > > > >> button, github-based comments can show as comments in apache JIRA. The > > > new > > > >> hbase-operator-tools and hbase-connector repos are gitbox based. We > > can > > > run > > > >> experiments there with fear of damage to the core. > > > >> > > > >> The justification is that if our project supported PRs and > > contribution > > > via > > > >> github, we could glean more contributors. > > > >> > > > >> Below I repeat two follow-on comments taken from the "Rough notes from > > > dev > > > >> meetup, day after hbaseconasia 2018, saturday morning" thread by way > > of > > > a > > > >> kickstart: > > > >> > > > >> From our Josh Elser: > > > >> > > > >>> This [supporting PRs] is something the PMC should take to heart. If > > we > > > >> are excluding > > > >>> contributions because of how we choose accept them, we're limiting > > our > > > >> own > > > >>> growth. Do we have technical reasons (e.g. PreCommit) which we cannot > > > >> accept > > > >>> PR's or is it just because "we do patches because we do patches"? > > > >>> > > > >> > > > >> By our Sean: > > > >> > > > >> "I don't want to bog down this thread, but there are a ton of > > > >> unanswered questions for allowing github PRs. > > > >> > > > >> "The biggest one for me is that JIRA is currently our best hope for an > > > >> authoritative place for authorship information. If we're taking PRs > > > >> from folks who have GitHub accounts but find ASF JIRA accounts too > > > >> burdensome, what are we putting for the author in JIRA? Am I going to > > > >> have to look in JIRA before a certain date and in Git after? Or in Git > > > >> only if JIRA is set to some "HBase Contributor from GitHub" account?" > > > >> > > > >> Thanks, > > > >> St.Ack > > > >> > > > > > > > > > > > > Hey folks, > > > > > > > > This authorship bit might be coming up now. There's a PR for an > > existing > > > > JIRA issue that I'd like to accept, but AFAICT the PR author doesn't > > > have a > > > > JIRA account. > > > > > > > > I've asked them about it. If they don't have an account and don't want > > to > > > > make one, I suppose I'll make a placeholder JIRA account and send the > > > > details to the PMC, unless someone objects. > > > > > > > > I'm not happy about the bifrucation of authorship information but I > > don't > > > > see how forcing JIRA account creation could possibly be sustainable. > > > > > > > >> > > > > >
