For code changes, patch files in Jira used to be the only option. Over the years, this is almost completely replaced by PRs, but we still leave the door open for patch in JIRA. We could apply the same principle here: Don't shut down JIRA, but change documentation so that GitHub issues is documented first. A contributor who for some reason is prohibited to use a GitHub account can then use the JIRA+patch workflow and CHANGES.txt will record the JIRA issue, in-between all the github-issues. BWT: All issues, both in JIRA and GitHub are readable to the public without a user account.
Jan > 6. mai 2022 kl. 05:15 skrev Tomoko Uchida <[email protected]>: > > Hi Yuting, > thanks for your feedback. > For your information, we have a general issue to improve our contribution > workflow: LUCENE-10543 <https://issues.apache.org/jira/browse/LUCENE-10543>, > and this is actually a sub-task of it. > You and anyone can contribute to it by leaving comments, creating > documentation or instruction for developers, or whatever else (if you'd > like!). > > I'll try to keep this thread a safe place for everyone though, I'd especially > appreciate feedback from newcomers like Vigya and Yuting, since I understand > and remember it is more difficult (and sometimes fearful) to join discussions > for new developers than long-time contributors. > > Tomoko > > > 2022年5月6日(金) 11:16 Yuti G <[email protected] <mailto:[email protected]>>: > Hi Tomoko, > > Thanks for raising this discussion! > > As a new member of the Lucene community, I'm also confused by the input > components when creating a Jira issue. I struggled with previewing my text > and had to edit it after creating a Jira issue or a comment, and I just found > that each re-edit would send an email notification to the list 😅 > > I only used the GitHub issue system on a small team scale and I am getting > familiar with Jira now. It would be very helpful if we can create a clear > instruction/guide for new developers on how to create an issue no matter > which system we choose in the future. > > Best, > Yuting > > On Thu, May 5, 2022 at 6:00 PM Tomoko Uchida <[email protected] > <mailto:[email protected]>> wrote: > I'm not going to thoroughly discuss the migration path from Jira to GitHub > here, but generally, the rough image in my mind is the same as Jan described > - "Milestone" for version tracking, and "labels" for other purposes (issue > types, component types, etc.). > > As for the proposal of in-house GitLab, it could be an option (if UI/UX is > the only problem) but I don't think it's feasible. > We need high availability platform and we don't have machine/human resources > to operate such mission-critical in-house service on our own. And, even if > it's possible, we still have to switch between two platforms - it doesn't > solve my problem. > > > That's precisely the crux of the disagreement: I want to be able to > > register > > an account at Apache and *not* GitHub and still be able to contribute. > > > Is the original Jira -> GitHub move just a change of defaults or are we, > > once moved to GitHub, not letting people use Jira at all anymore ? > > Interesting point - is there anyone else who doesn't have or use GitHub > account and *won't sign up or sign in for it* ? > > Tomoko > > > 2022年5月6日(金) 7:04 Uwe Schindler <[email protected] <mailto:[email protected]>>: > I agree with that. > > What annoys me is that I have to open a fake issue in Jira. I think we should > allow people to open GitHub PR or issues. It gets reported also to mailing > list. If a Lucene committer does not want to use GitHub, heshe can just > download the PR as patch file and apply. Same for issues: all is mirrored to > mailing list. > > If our users want to open issues they should do what they prefer. > > Uwe > > Am 5. Mai 2022 21:50:58 UTC schrieb Michael Sokolov <[email protected] > <mailto:[email protected]>>: > Is the original Jira -> GitHub move just a change of defaults or are we, > once moved to GitHub, not letting people use Jira at all anymore ? > > Nothing has been decided - it's all open for debate. > > I just want to re-state the idea (at least as I heard it) behind this > proposed move is to make contributing more accessible. > > As for github banning people, just google "github banning" and you > will see that people have been banned for a variety of reasons. > > I don't know if the risk of that outweighs the inconvenience of JIRA > for the new developer. > > Please note that the primary avenue for contributions today *is > already github*. So far we have not had any issues with people being > banned, and if that were to happen, we still accept patch files in > JIRA. We have had these two mechanisms in place for quite a while now > and both are in active use. > > But this proposal is about issue tracking anyway: I just point out > that we already rely on github in spite of its shortcomings. > To unsubscribe, e-mail: [email protected] > <mailto:[email protected]> > For additional commands, e-mail: [email protected] > <mailto:[email protected]> > > -- > Uwe Schindler > Achterdiek 19, 28357 Bremen > https://www.thetaphi.de <https://www.thetaphi.de/>
