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 <[email protected]>, 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+
>
> 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: [email protected]
> For additional commands, e-mail: [email protected]
>

Reply via email to