Ron, I re-read what you wrote and I guess I misunderstood. I thought you meant to add a category to contact the Lucene.NET development team directly (via the mailing list). But, although I don't have an issue with discussing API design on the mailing list in principle, the fact is that discussing API design using plain text rather than markdown is quite a burden. AFAIK, the Apache mailing lists don't support rich text (HTML) email.
My thought originally was to discuss "API Changes" in the "Feature Request" category, which seems to be the logical place to do it for lack of other options. They seem to overlap, anyway. I don't have an issue with adding a link to instructions on how to use the dev list, though, and to leave it open to "development discussion". I wonder what others think about enabling the GitHub "discussions" feature to do broad questions? The IKVM project has enabled them, and people do use them to talk about various things that aren't items to be worked on, but that generally also includes usability issues. But they also talk broadly about what to include in releases and such. https://github.com/orgs/ikvmnet/discussions ASP.NET Core also has it enabled. https://github.com/dotnet/aspnetcore/discussions That said, I don't know if other Apache projects are using them and I am not sure they would get archived by Apache or count toward "activity" in the quarterly reports. Shannon, GitHub discussions might work a bit better for "when is the release?", but I think eliminating the noise from the issues list would pretty much get us a pared down inventory of the remaining work (except for it is spread across multiple repositories). I don't like the idea of maintaining the remaining work in both "issues" and a separate document, though because the separate document would quickly go out of date (as is the CONTRIBUTING.md page as well as the WIKI). But maybe if we use some sort of label/milestone scheme, we could have a "status" page dynamically driven from the issues to show a single view of the remaining work across lucenenet, ICU4N, and J2N (which is basically driven by the needs of the other two). Thanks, Shad Storhaug Project Chairperson - Apache Lucene.NET -----Original Message----- From: [email protected] <[email protected]> Sent: Friday, October 20, 2023 9:47 PM To: [email protected] Subject: RE: GitHub Issue/PR Templates 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 <[email protected]> Sent: Friday, October 20, 2023 10:20 AM To: [email protected] 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: [email protected] <[email protected]> Sent: Friday, October 20, 2023 7:54 PM To: [email protected] 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 <[email protected]> Sent: Friday, October 20, 2023 7:45 AM To: [email protected] 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
