-1 I think the disruption and bifurcation of where to find history is not worth it. I also noticed a comment in the lucene issue for migration with summaries by date range, status, affects version, etc. sub-area, exactly the sort of thing I expect to be much more difficult to obtain from github. What I would find interesting is a deep integration of the two systems so that initiation and basic commenting could be handled on github, but transmitted to Jira where full metadata and reporting/tracking could be maintained.
On Tue, May 31, 2022 at 12:17 AM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > -1 > > On Tue, 31 May, 2022, 4:06 am Xi Chen, <zacharym...@yahoo.com.invalid> > wrote: > >> +1 from me (committer, non-PMC) >> >> Thanks Tomoko for starting the discussion and organizing / leading this >> effort! >> >> Best, >> Zach >> >> On May 30, 2022, at 2:56 PM, Houston Putman <hous...@apache.org> wrote: >> >> >> +1 Approve (PMC) >> >> Thanks so much for doing all of the work for this Tomoko! >> >> - Houston >> >> On Mon, May 30, 2022 at 5:38 PM David Smiley <dsmi...@apache.org> wrote: >> >>> +1 Approve (PMC) >>> >>> ~ David Smiley >>> Apache Lucene/Solr Search Developer >>> http://www.linkedin.com/in/davidwsmiley >>> >>> >>> On Mon, May 30, 2022 at 11:40 AM Tomoko Uchida < >>> tomoko.uchida.1...@gmail.com> wrote: >>> >>>> Hi everyone! >>>> >>>> As we had previous discussion thread [1], I propose migration to GitHub >>>> issue from Jira. >>>> It'd be technically possible (see [2] for details) and I think it'd be >>>> good for the project - not only for welcoming new developers who are not >>>> familiar with Jira, but also for improving the experiences of long-term >>>> committers/contributors by consolidating the conversation platform. >>>> >>>> You can see a short summary of the discussion, some stats on current >>>> Jira issues, and a draft migration plan in [2]. >>>> Please review [2] if you haven't seen it and vote for this proposal. >>>> >>>> The vote will be open until 2022-06-06 16:00 UTC. >>>> >>>> [ ] +1 approve >>>> [ ] +0 no opinion >>>> [ ] -1 disapprove (and reason why) >>>> >>>> Here is my +1 >>>> >>>> *IMPORTANT NOTE* >>>> I set a local protocol for this vote. >>>> There are 95 committers on this project [3] - the vote will be >>>> effective if it successfully gains more than 15% of voters (>= 15) from >>>> committers (including PMC members). This means, that although only PMC >>>> member votes are counted for the final result, the votes from all >>>> committers are important to make the vote result effective. >>>> >>>> If there are less than 15 votes at 2022-06-06 16:00 UTC, I will expand >>>> the term to 2022-06-13 16:00 UTC. If this fails to get sufficient voters >>>> after the expanded time limit, I'll cancel this vote regardless of the >>>> result. >>>> But why do I set such an extra bar? My fear is that if such things are >>>> decided by the opinions of a few members, the result shouldn't yield a good >>>> outcome for the future. It isn't my goal to just pass the vote [4]. >>>> >>>> [1] https://lists.apache.org/thread/78wj0vll73sct065m5jjm4z8gqb5yffk >>>> [2] https://issues.apache.org/jira/browse/LUCENE-10557 >>>> [3] https://projects.apache.org/committee.html?lucene >>>> [4] I'm sorry for being overly cautious, but I have never met in person >>>> or virtually any of the committers (with a very few exceptions), therefore >>>> cannot assess if the vote result is reliable or not unless there is certain >>>> explicit feedback. >>>> >>>> Tomoko >>>> >>> -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
