: Subject: Re: Solr patches for 4x - how to get committer attention? FWIW: there is a big difference between getting attention for a patch, and getting attention for an open issue that has no patch -- several of the issues you mentioned have no patch at all, which doesn't really put them on the same playing field.
The concern is that sort of situation should not be "how do i get committer's attention" as "how can i help contribute to moving this forward, and how do i rally other people into thinking this feature/bug is important enough to get them to also want to contribute as well." Even if you don't know how to fix a bug, or implement a desired feature: take a stab at writing a test case that demonstrates the problem and/or how you think things should work. That saves time for someone (committer or othwerwise) to work on implementing the code to make th test pass -- or at the very least, helps start the conversation as to what the code should look like. the more active an issue is, the more people work on a patch, the more iterations there are as people help find problems and fix them, the more people say "this patch works well for me" -- the more likely it is to get the attention of someone to do that last little bit: commit the thing. For me, these past few weeks, i've really been trying to prioritize my time on committing fixes for bugs (in particular: silent bugs that users may not even notice). if someone else has already submitted a patch with a text & a fix, great, that saves me time and i try to tackle those as soon as i see them -- all i have to do is sanity check it and commit. if someone has submitted a patch with just a test, or just a fix -- that's more work, but still better then nothing, i try to work on those as soon as i have an idea how to deal with them. last on the list is bugs with no test or proposed fix ... those tend to take the most amount of time/energy/thought, so unless the description makes it clera that they are really heinous and/or have no work arround, they tend to be at the bottom of the queue. New features tend to enter my thought process the same way -- they just have a higher burden in my own mind before i'm confortable committing them, because they open up the "expected functionality" vectors of solr, and it takes some careful consideration of what the long term support/viability of a feature is realtive other features/refactorings might be desirable -- the bigger the feature, the more surface area it exposes, the more carefully i want to think it through and think about how it interacts with other features (and see tests verifying how well it works in conjunction with other features) before i'm confortable committing. -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
