Thanks everyone for your thoughtful comments - I think we can learn a lot from Solr Operator project.
And then, I'd appreciate the feedback from Julie; not only because of the support for the migration but also because we surely need feedback from committers/contributors who actively create or review patches/PRs on a regular basis and drives this project like you. Of course, advisory comments from the whole community are really helpful and I welcome feedback from all developers, regardless of the activities on Lucene. I don't think I'm good at facilitation, I'll try to be here though :) I hope we'll continue a good conversation, and then, we can be confident opening the official vote. Tomoko 2022年5月11日(水) 9:36 Julie Tibshirani <juliet...@gmail.com>: > 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 >>> >>>
