Shad, > I don't think we should discard the whole template, though - it is helpful to know ahead of time if your PR is likely to get rejected. This is something that can help to increase contributions, even though on the surface it appears as a detractor.
I agree. > But on the other hand, if we required an open issue first we could eliminate wasting everyone's time by having someone do the work to submit a PR and us having to review it only to reject it because they didn't bother to discuss whether we would accept such a PR. > I see that too. It's a fair point. > BTW - one thing I also considered that both Lucene and ASP.NET Core have is a "Test" issue category. In ASP.NET Core, it is to report a failing test to quarantine. In Lucene, it is to report a test failure or request a new test. Not sure we need either one of these, but I would like to hear others weigh in on it. I wouldn't. Simpler is better. > There is also a way to have a "General" category that allows the user to pass through without a template as would be the case without setting up the templates. We could use it to see if there are any issues that cannot be categorized any other way that we need to address as a new template, but it also gives the user the ability to abuse our issues list by submitting issue spam like we have now. I think it's better without a "General" category. Having such a category could negate the desired process improvement. It's be interesting to see what thoughts other devs chime in with. -Ron Clabo Apache Lucene.NET Committer -----Original Message----- From: Shad Storhaug <s...@shadstorhaug.com> Sent: Friday, October 20, 2023 10:20 AM To: dev@lucenenet.apache.org Subject: RE: GitHub Issue/PR Templates Thanks for the feedback Ron! > As for whether the dev mailing list should be on that page under some category...to me, it feels like it should. I guess I'd kinda expect to see it under a category that is something like ".NET specific API improvements" maybe with a description like "Please discuss all .NET specific API improvements on the Lucene.NET developer mailing list. This provides an opportunity for the community to way in and helps us gauge the level of interest in the proposed improvement." Agreed. This sounds like a good addition. As for the PR checklist, I see your point. I don't think we should discard the whole template, though - it is helpful to know ahead of time if your PR is likely to get rejected. This is something that can help to increase contributions, even though on the surface it appears as a detractor. But perhaps we should limit the checkboxes to only the first 3. Opening an issue first is sort of the norm on most repositories and that is what experienced contributors often do, but I am not sure it really needs to be a requirement. I also often submit PRs that don't have a related issue and it would slow me down if I had to take that extra step. But on the other hand, if we required an open issue first, we could eliminate wasting everyone's time by having someone do the work to submit a PR and us having to review it only to reject it because they didn't bother to discuss whether we would accept such a PR. That is specifically what the "Don't push your pull requests" article we link to is about: https://www.igvita.com/2011/12/19/dont-push-your-pull-requests/. BTW - one thing I also considered that both Lucene and ASP.NET Core have is a "Test" issue category. In ASP.NET Core, it is to report a failing test to quarantine. In Lucene, it is to report a test failure or request a new test. Not sure we need either one of these, but I would like to hear others weigh in on it. There is also a way to have a "General" category that allows the user to pass through without a template as would be the case without setting up the templates. We could use it to see if there are any issues that cannot be categorized any other way that we need to address as a new template, but it also gives the user the ability to abuse our issues list by submitting issue spam like we have now. One more thing to keep in mind is that if the user goes through an issue template, it is possible to automatically tag the issue, which can help us build more automation as a response to a specific category of issue. Thanks, Shad Storhaug Project Chairperson - Apache Lucene.NET -----Original Message----- From: ron....@giftoasis.com <ron....@giftoasis.com> Sent: Friday, October 20, 2023 7:54 PM To: dev@lucenenet.apache.org Subject: RE: GitHub Issue/PR Templates I love the work on the https://s.apache.org/lucenenet-issue which I stated in my other response. But I have mixed feelings about the about the PR checklist. On one hand, the checklist is not unreasonable, but on the other hand, it's likely to reduce contributions, and I think in general we'd like to increase community contributions if we can get the community focused on the actual work that needs to be done. Especially in light of the new guidance being given on issues I feel like it might be good to give a bit of time to see how that improves things before rolling the https://s.apache.org/lucenenet-pr checklist approach. Just a thought. -Ron Clabo Apache Lucene.NET Committer -----Original Message----- From: Shad Storhaug <s...@shadstorhaug.com> Sent: Friday, October 20, 2023 7:45 AM To: dev@lucenenet.apache.org Subject: GitHub Issue/PR Templates Hello all, I have been working on setting up some issue and PR templates in GitHub so we don't have people submitting "How-To" questions and PRs for features from newer versions of Lucene - issues that eat up a lot of our time to review. https://s.apache.org/lucenenet-issue https://s.apache.org/lucenenet-pr Let's consider this a draft. I am just looking for some feedback from the Lucene.NET committers (and community) to make sure the templates fit in with our goals and Apache policies before we add them to our repository. I took a lot of pointers from both the Lucene repository and ASP.NET Core repository. https://github.com/apache/lucene/issues/new/choose https://github.com/dotnet/aspnetcore/issues/new/choose Please let me know if you think there are things that need polishing, categories to be added, or language that needs to be softened or made more inclusive. Thanks, Shad Storhaug Project Chairperson - Apache Lucene.NET
