Hi Tomoko, thanks for raising this! I am always in favor of simplicity and with the idea that code should speak for itself(readable code and meaningful commit messages over dirty code covered by a detailed Jira issue).
Now, given that, I have been using Jira for many years, I agree with all the limitations mentioned so far but I am generally happy about using it. I have limited experience with the Github issue system, it looks definitely "simpler" than Jira, not sure it covers all our requirements. Being a bit provocative and thinking out loud, I see a true necessity of raising issues(Jira or Github) in these instances: 1) proposal that needs discussion and doesn't have a clear solution 2) raise a bug/task/story we are not planning to do ourselves immediately (so we want to give the community the chance of doing it while we are busy) 3) planning, using sprints etc (we don't do) Whenever we have a contribution or bugfix ready (as an output of our daily working activity), it feels to me that it's unnecessary to create an issue at all, modern pull requests are perfectly fine for adding all the necessary details, tag people for review or discuss the contribution: to me having to open any kind of issue is just an unnecessary boilerplate activity (and duplication of description, comments, etc). Pretty sure I am missing something, but I just wanted to give a quick glance of a recent feeling of mine. Long story short, if the Github issue system covers all our requirements, I think it's going to be beneficial to keep all in the "same" place and would ease contributions. But I am arguing we should not open an issue for each contribution, most of the time the Pull Request should be enough. Of course, we should estimate the effort, identify people that realistically want to work for that and then vote if the amount of dedication is worth. In regards to nationality bans, and sanctions etc, I am personally not that worried, aren't we relying quite strongly already on Github for the repos, pull requests, etc?(and I assume many other infrastructures potentially owned by organizations that could impose certain bans?) Ideally, we want to just use tools owned by the Apache Software Foundation, but realistically sometimes you need to compromise. I would suggest we organize a voting session to see how strong the banning concern is, across the committers community, because generally, I think it's a fair point. Finally, I would like to raise a question: does anybody know if it's possible to create automatically "CHANGES" on GitHub, based on pull requests and merges maybe(or issues)? We were discussing removing the necessity of the (pretty annoying and error-prone) "CHANGES.txt", and wondering if Jira could automatically solve that necessity. If GitHub is better at that, could be a strong incentive to go in that direction! Cheers -------------------------- *Alessandro Benedetti* CEO @ Sease Ltd. *Apache Lucene/Solr Committer* *Apache Solr PMC Member* e-mail: a.benede...@sease.io *Sease* - Information Retrieval Applied Consulting | Training | Open Source Website: Sease.io <http://sease.io/> LinkedIn <https://linkedin.com/company/sease-ltd> | Twitter <https://twitter.com/seaseltd> | Youtube <https://www.youtube.com/channel/UCDx86ZKLYNpI3gzMercM7BQ> | Github <https://github.com/seaseltd> On Tue, 10 May 2022 at 06:04, Tomoko Uchida <tomoko.uchida.1...@gmail.com> wrote: > I'll keep open this thread for a while - while almost all concern for the > transition seems to be already on the table, I feel we'd need more > participation from committers who actively work for this project. Without > mature discussion among active committers and contributors, the vote would > not yield a good result whether it is passed or not. > > I don't want to disturb the coming release so I'm not going to move this > until the 9.2 release is done; but please feel free to leave comments. > > Tomoko > > > 2022年5月10日(火) 11:06 Tomoko Uchida <tomoko.uchida.1...@gmail.com>: > >> Thank you Robert for your feedback. >> >> I'm also sorry if my previous mail was urging explicit feedback - I >> understand such a request goes against the "lazy consensus" practice in >> Apache. >> I'd be grateful to hear thoughts or simply +1 / -1 / +-0 from developers >> who are actually affected by this proposal if you are interested. >> >> Thanks, >> Tomoko >> >> >> 2022年5月10日(火) 9:36 Robert Muir <rcm...@gmail.com>: >> >>> On Mon, May 9, 2022 at 7:59 PM Tomoko Uchida >>> <tomoko.uchida.1...@gmail.com> wrote: >>> > >>> > Also, I have a great deal to be concerned about "what active >>> committers/contributors on Lucene actually think of it". >>> > >>> >>> I have a couple thoughts. >>> >>> 1. What percentage of contributions are done via pull requests versus >>> via patch files these days? I'm always happy to commit a patch, but I >>> just don't see them. I'm still happy to commit a patch sent to the >>> mailing list. I feel that requiring JIRA is just unnecessarily >>> invoking another tool, another signup process, unnecessary hurdle. If >>> someone wants to send a patch to the mailing list, e.g. from the user >>> list as part of a discussion, that's fine. >>> 2. Realistically, every committer actively merging/committing is using >>> github today already. This proposal doesn't make their life any more >>> difficult. They already have their github account setup. It makes life >>> easier for the *contributor*, which is what I want. >>> 3. Around concerns of github "censorship" and certain countries, this >>> doesn't affect public repositories, just private ones. It has to do >>> with sanctions and money and so on. I see you committed Persian >>> Stemmer from an Iranian contributor just this morning. This is not a >>> problem. >>> 4. Still along these lines, I tested this stuff from behind chinese >>> great firewall this morning, to have the full experience myself. >>> lucene.apache.org site is extremely fast, fastly CDN! github.com was a >>> bit slower to load, but not terrible. Loading up JIRA >>> (issues.apache.org) was very slow, required both getting and drinking >>> another coffee. It is some machine out there in hetzner germany, which >>> may be the issue. At the same time, I think it is unreasonable to ask >>> infra to "cluster" the JIRA for better access around the world, >>> because that's absurdly scary from a technical perspective. So I'm >>> happy if we can streamline the contribution process and make it easier >>> for folks outside of US and europe. >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >>>
