Hey David, Thank you for doing this! I don't have good ideas for new good first issues.
However, something that we need to periodically do and hasn't been done in a long time now is taking a look at the slower Lucene tests and checking if they are slow for a good reason or not. Some tests are slow for a good reason (e.g. PostingsFormatTestCase and DocValuesFormatTestCase sub classes usually), but often, they are not slow for a good reason but because they do too much merging or index many documents with the SimpleText codec. For instance I've seen TestPriorityQueue and TestLateInteractionRescorer often take several seconds recently, I'm not sure if this is needed. There are likely many other tests in this case. This could be a good opportunity to get familiar with Lucene's tooling (tests.slowestTests, tests.profile, etc.), how Lucene works (text analysis, indexing, merging, searching), and getting a first change in. I wouldn't mind separate PRs for each slow test that gets a speedup to help share this task across multiple participants to the Hackathon. On Wed, Sep 10, 2025 at 6:16 PM David Smiley <dsmi...@apache.org> wrote: > I'll be running a hackathon tomorrow at Community-over-Code with Nazerke. > I'll be sharing the "good first issue" issues as a potential list of items > for new contributors: > https://github.com/apache/lucene/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22good%20first%20issue%22 > (only 9 issues as I write this) > > You can help our project & contributors & hackathon simply by doing a > little label grooming. If you created an issue recently and think it's a > "good first issue" for a contributor then add it! Come to think of it, > maybe even some bugs might be such. Or maybe something on your mind hasn't > been filed yet; please do! > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > -- Adrien
