Thank you Mike for opening the discussion. I don't really have a clear "opinion" on that, but I just wanted to try to explain my perspective.
Today almost all development is already going on GitHub pull requests, then it would be a natural direction for the majority of devs to move our primary conversation platform to GitHub. I think we should try to optimize our environment for majorities, although I know we will never be able to reach a unanimous agreement. Meanwhile, it was not my intention to completely discontinue the contribution path via Jira. I rather optimistically thought we could leave room for developers who don't use GitHub for any reason. As for preventing someone from "accidentally" opening Jira issues, we could show a text that says "Jira has been deprecated. Please open GitHub issue unless you are not able to do so." when he/she is attempting to open Jira. https://confluence.atlassian.com/adminjiraserver/configuring-contexts-and-default-values-for-the-description-field-1047552727.html I agree that it'd be the cleanest way to make Jira read-only and I myself am fine with the proposal - maybe I'm overthinking. Tomoko 2022年7月17日(日) 22:13 Michael McCandless <luc...@mikemccandless.com>: > Hi Team, > > Thanks to Tomoko's amazing hard work ( > https://github.com/apache/lucene-jira-archive), we are getting close to > having strong tooling and a solid plan to migrate all past Jira issues to > GItHub issues! > > But one contentious point is whether to leave Jira read-only or read-write > after the migration. So let's DISCUSS and maybe VOTE to reach concensus? > > My opinion: I think it'd be crazy to leave Jira read/write. We would > effectively have two issue trackers. New users who find Jira through > Google, or through links we have in old blog posts, etc., might > accidentally open new Jira issues or comment on old ones and we may not > even notice. I think that would harm our community. > > I would prefer that we make a nearly atomic switch -- up until time X we > use Jira, then it goes read-only and at time X + t (t being how long the > migration takes, likely a day or two?), GitHub issues opens for business. > This way we clarly have only one issue tracker at (nearly) all times. This > would make a clean migration, and reduce risk of trapping users. > > Other opinions? > > Thanks, > > Mike > -- > Mike McCandless > > http://blog.mikemccandless.com >
