I created an infra "wish" that relates somewhat to this as well... https://issues.apache.org/jira/browse/INFRA-18518 I also don't like D. There definitely needs to be only one place to search for issues. I don't like E either, while convenient from github their issue system has way fewer features, and I suspect even if we can port issues to it to keep the "one place" that will be lossy. As an example how would you implement the security issue visibility with original poster and PMC able to see it in github? I don't think they have a notion of roles/access control that is comparable. (or I'm simply unaware of it)
-Gus On Fri, Jun 7, 2019 at 2:45 PM Cassandra Targett <[email protected]> wrote: > I created an issue for this at > https://issues.apache.org/jira/browse/LUCENE-8842, and I’ll use that to > create a branch and push up what I have so far for a template. > > Cassandra > On Jun 7, 2019, 11:31 AM -0500, Kevin Risden <[email protected]>, wrote: > > 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 <[email protected]> > 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 <[email protected]> > 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 <[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+ > <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: [email protected] > For additional commands, e-mail: [email protected] > > -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
