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 <[email protected]> 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 <[email protected]> wrote: > >> >> >> On Tue, May 10, 2022 at 10:40 AM Houston Putman <[email protected]> >> 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 > >
