PR template would definitely be good. Easiest to implement with biggest impact. I like that all issues are in Jira. There is already an infra bot that will auto link Jiras and PRs if the PR has the a JIRA reference in it I think.
For reference this is also the idea of contributing guidelines in addition to the PR template [1] There are a few types of files that would help people if they stumble on the github repo [2]. [1] https://help.github.com/en/articles/setting-guidelines-for-repository-contributors [2] https://help.github.com/en/articles/creating-a-default-community-health-file-for-your-organization Kevin Risden On Fri, Jun 7, 2019 at 9:58 AM David Smiley <david.w.smi...@gmail.com> wrote: > I think a PR template would be great. Lets see yours Cassandra! > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Fri, Jun 7, 2019 at 9:35 AM Cassandra Targett <casstarg...@gmail.com> > wrote: > >> Heh, here’s another idea I’ve had in my drafts folder for a while but >> thought if I suggest it I should be available to follow up on it and wasn’t >> sure if I’d have time to properly. >> >> I actually started a pull request template and have a mostly complete >> version I could share (via a PR, I guess?). I don’t think it will 100% >> solve it, but it would greatly increase the number of issues that comply, >> for lack of a better term, with our processes/expectations for changes. In >> my draft I also included a short checklist to encourage people to make >> the patch for master, include tests with their patches, run precommit, >> and a few other things I thought might help new contributors understand >> what we need to get their patches reviewed faster. >> >> Your D and E ideas are interesting. I worry about fragmenting where >> definitive info about changes is stored (D) - I think there is a lot of >> value in having a single system of record for the community. >> >> I’d definitely be for exploring moving entirely to Github (E) - I think I >> said something along those lines in the lucene-solr Slack channel a few >> months ago - but have not spent much time figuring out all the downstream >> implications. I think we’d have to consider what we would gain vs what we >> would lose. I definitely don’t yet have a list, but I’m not initially >> against the idea. >> >> Cassandra >> On Jun 7, 2019, 5:53 AM -0500, Jan Høydahl <jan....@cominvent.com>, >> wrote: >> >> Hi, >> >> We have some contributors that open GitHub PRs without also opening a >> JIRA and linking the two. Probably because they are used to that workflow >> from other projects and expect someone to have a look at the contribution. >> There is an email sent to the dev list, and sometimes it is noticed, other >> times the PR just falls through the cracks and is forgotten. >> >> Here is a list of currently open PRs without a JIRA attached, 51 in total: >> >> >> https://github.com/apache/lucene-solr/pulls?utf8=✓&q=is%3Apr+is%3Aopen+NOT+LUCENE+in%3Atitle+AND+NOT+SOLR+in%3Atitle+ >> <https://github.com/apache/lucene-solr/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+NOT+LUCENE+in%3Atitle+AND+NOT+SOLR+in%3Atitle+> >> >> How can we improve on the situation? I see a few alternatives: >> >> A. Setup a bot with a GitHub WebHook that inspects the title and auto >> adds a comment if LUCENE or SOLR is missing >> https://developer.github.com/v3/activity/events/types/#pullrequestevent >> B. Send the result of the above query to the dev@ list monthly for >> someone to jump in and interact >> C. Add a GitHub Pull-Request Template >> https://help.github.com/en/articles/creating-a-pull-request-template-for-your-repository >> In there put some text about the requirement for a JIRA >> D. Treat PRs as first-class issues, without the need for a shadow JIRA. >> In that case, we'd reference PRs in CHANGES too, e.g.: >> * #217: Fix bug foo >> E. Migrate away from JIRA and use GitHub issues + PR instead. Some Apache >> projects do that already :) >> >> Let the discussion begin :) >> >> -- >> Jan Høydahl, search solution architect >> Cominvent AS - www.cominvent.com >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >>
