Once we get C in place (Github PR template), this will hopefully fix itself. So I propose to try PR template as a first measure and then revisit if that is not enough.
Still left to do is to triage the existing open PRs and link them. Who wants to help? https://github.com/apache/lucene-solr/pulls?utf8=✓&q=is%3Apr+is%3Aopen+NOT+LUCENE+in%3Atitle+AND+NOT+SOLR+in%3Atitle+ We should probably also look for PRs with a LUCENE/SOLR jira attached, where the fix is merged without auto-closing PR, and then close those. TIP: When you merge code outside of github, add the text "fixes #123" to the commit message to automatically close PR#123. -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com > 10. jun. 2019 kl. 15:05 skrev Gus Heck <[email protected]>: > > Or the committer can create it if the issue is truly trivial... Also, one of > the things that folks who contribute may gain is learning about development > process. That aspect was extremely helpful to me when I made my first > contributions to Ant many years ago. Not everyone who contributes is an > expert. > > On Mon, Jun 10, 2019 at 3:33 AM Varun Thacker <[email protected] > <mailto:[email protected]>> wrote: > I think D is important for making the barrier low for new contributors to get > started. > > It won't be great as we'll have two places to look a CHANGES entry against > but I'll be okay with that. > > Today a new contributor creates a PR and a committer can even merge the PR > from the github interface. But in between those 2 steps we have to tell the > contributor to go create a placeholder Jira. > > Imagine if this new contributor just wants to fix one typo from the ref > guide. The overhead involved will shun quite a lot of folks? > > On Sat, Jun 8, 2019 at 2:22 PM Jan Høydahl <[email protected] > <mailto:[email protected]>> wrote: > Jira has become very heavy-weight over the years and I'm not sure we need all > those features. > I think Github issues are a bit too lightweight perhaps, so I'm not actively > promoting option E, just lifting it up as a real alternative. > >> As an example how would you implement the security issue visibility with >> original poster and PMC able to see it in github? > > Think they have something in the makings for this, see > https://github.com/apache/lucene-solr/security/policy > <https://github.com/apache/lucene-solr/security/policy> > Have no idea if you can limit the group who sees them to PMC members though. > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com <http://www.cominvent.com/> > > > > -- > http://www.needhamsoftware.com <http://www.needhamsoftware.com/> (work) > http://www.the111shift.com <http://www.the111shift.com/> (play)
