I don't have much to add to the (already very detailed!) discussion, just wanted to add my support for the idea of moving to GitHub. I've had a good experience with GitHub issues for other repos I contribute to and find the mark-up language comfortable and expressive. I also think switching to GitHub could help newer contributors engage with the project. When I first started contributing I found it really hard to navigate and search JIRA for issues I was interested in. Now I rely on Mike's wonderful JIRA search tool (https://jirasearch.mikemccandless.com/search.py), but most new contributors do not know about it (and it adds another dependency on top of GitHub and JIRA).
Julie On Tue, May 10, 2022 at 12:41 PM Houston Putman <hous...@apache.org> wrote: > I'm not going to get into how the Github automation should be done, that's > a whole separate thread. But I agree too much automation can certainly be > annoying and a burden. You can see this a lot in the kubernetes repos ( > https://github.com/kubernetes), though it does come with its reasons. > > Kubernetes is a good example of a project MUCH bigger than Solr > successfully using Github Issues & PRs. So I don't really think it's a > question if Github is feature-rich enough to handle our use case, it's > pretty clear that it is. It will certainly be a change in process, but I > think that all of these very successful open source projects show that it's > a valid option for our projects. I think the ultimate questions are: > > - Which will be easier for users to find relevant information? > - Which reduces the amount of bureaucracy needed to contribute to the > project? > - Which fits into the workflows of existing committers the best? > > To me Github comes up on top, even though there are things that JIRA does > better. > > P.S. I think you mean https://github.com/helm/charts, marcus. I don't > think helm is deprecated > > On Tue, May 10, 2022 at 1:41 PM Marcus Eagan <marcusea...@gmail.com> > wrote: > >> I recommend people take a look at the now deprecated helm project. It was >> very difficult to land PRs because they had so much governance and >> automation. For a data store as mature as SOLR, I would suggest it is >> needed. >> >> Many issues are worth a read: https://github.com/helm/helm >> >> On Tue, May 10, 2022 at 10:16 AM Gus Heck <gus.h...@gmail.com> wrote: >> >>> >>> >>> On Tue, May 10, 2022 at 10:40 AM Houston Putman <hous...@apache.org> >>> wrote: >>> >>>> >>>>> >>>> Most modern open source projects use Github Issues for their issue >>>> tracking, so it's definitely doable, and really what new >>>> users/contributors will be expecting. Also I see that much discussion is >>>> already done on PRs, and JIRAs are mainly there just for >>>> bureaucratic purposes. So I think it would be a wonderful direction to go >>>> in. >>>> >>>> >>> On that note, many such projects I find it more difficult to get clarity >>> on whether or not I'm affected by the issue, or in what version it was >>> resolved. Usually i can be achieved by clicking on the referenced commit, >>> and then inspecting what tags are on that commit, but it's several clicks >>> and a minute or two vs just looking at the field in Jira... >>> >>> This can be made easier by using milestones as seen here (random >>> example, used gradle because it's a very large, healthy project): >>> https://github.com/gradle/gradle/issues/20182 >>> >>> But I've seen a lot of projects that don't do that... which probably >>> colors my view a bit. >>> >>> -Gus >>> >>> -- >>> http://www.needhamsoftware.com (work) >>> http://www.the111shift.com (play) >>> >> >> >> -- >> Marcus Eagan >> >>
