#1 for me too, it’s the no nonsense common sense approach and personally I feel this project is unsustainable over the longterm if we encourage people to think they’ve contributed anything at all when filing a JIRA issue poorly and never return to answer questions about steps to reproduce.
The GitHub discussion approach entails that filing an issue is just the starting point of engagement as well as ownership. Dumping the thousands of issues with people complaining and not contributing is the right way to go — those that truly care will pick up their discussion on GitHub. We should formally announce that we’re no longer accepting issues, just discussions, in which the reporter owns what they report on, from the start to the end (i.e., testing) of the process. Gj On Sat, 4 Dec 2021 at 04:12, Vano Beridze <[email protected]> wrote: > #1 is the way to go > > On Fri, Dec 3, 2021, 6:13 PM Nicola Ken Barozzi <[email protected]> > wrote: > > > Having started recently with the community, I would go with #1. > > > > The more the system is integrated and evident in how it works > > together, the easier it is for others to contribute. > > > > > > On Fri, Dec 3, 2021 at 12:19 PM Neil C Smith <[email protected]> > > wrote: > > > > > > On Thu, 23 Sept 2021 at 15:42, Neil C Smith <[email protected]> > > wrote: > > > > I've long felt that our use of JIRA and poor integration with the PR > > > > process, etc. is more of a hindrance than a help, particularly during > > > > releases. > > > > > > Thanks everyone who has input here. Now 12.6 is out (just about) and > > > branching for 13 is knocking on the door in mid-January, it would be > > > good to wrap this discussion up into a plan that we can put in place > > > by then. > > > > > > I think we have four options - > > > > > > 1. Move to GitHub issues, porting Airflow's model, configuration and > > > automation, adapting where needed - > > > > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191332632 > > > > > > 2. Stick with JIRA, but seek to address the sync issues between the > > > two systems, including PRs, milestones, assignees, etc. As well as > > > issue templates, removing access to fields like priorities, etc. from > > > users? Add automation? Potentially make sure all PRs have a valid > > > ticket? > > > > > > 3. Stick with JIRA as configured now. > > > > > > 4. Ignore JIRA issues entirely as part of the release process. > > > > > > > > > I've made no secret I'm in favour of #1. And I'm happy to put some > > > time into making that happen. Maybe others too? > > > > > > If #2, then some one/group needs to make that happen, and outline how, > > > liaise with infra@ if needed, etc. Who's up for it? Is it actually > > > doable? Happy to help here too, but it's going to be a lot more > > > limited. > > > > > > Neither #3 or #4 feel tenable to me, although we're getting closer to > > > #4 each release. If you're in favour of #3, thanks for offering to > > > take on the next release though! ;-) > > > > > > Is there a #5? > > > > > > Best wishes, > > > > > > Neil > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > For further information about the NetBeans mailing lists, visit: > > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > > > > > > > > > > > > -- > > Nicola Ken Barozzi [email protected] > > - verba volant, scripta manent - > > discussions get forgotten, just code remains > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > For further information about the NetBeans mailing lists, visit: > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > > > > > >
