We should start a new thread about Discussions so it can be clearly and specifically discussed..i.e not on this thread or the other previous thread both originally about Issues.
On Thu, 18 Apr 2024 at 16:32, Christopher Shannon <christopher.l.shan...@gmail.com> wrote: > > I think overall it would be a positive thing, it gives a place for people > to ask questions without having to raise a Jira. > > I guess the one downside is it would be something else to monitor...there's > already Jira, Slack, and the mailing lists. > > I think one thing that would be helpful for monitoring is for the > discussions to be mirrored to email so people can monitor it in one spot, > and even respond to by email if they want. I assume that the discussions > can be emailed just like the notifications for PRs so that people don't > need to check. I'm not sure if it would be better for the discussion > threads to be mixed in with the existing notifications for PRs or another > mailing list. We can always set up filters so sharing the existing > notification list is probably ok. > > On Thu, Apr 18, 2024 at 10:50 AM Justin Bertram <jbert...@apache.org> wrote: > > > Enabling GitHub Discussions is not something we've really discussed > > thoroughly. I mentioned it in my review only briefly as a "future > > consideration." I don't think we've got consensus yet. > > > > > > Justin > > > > On Thu, Apr 18, 2024 at 8:47 AM Christopher Shannon < > > christopher.l.shan...@gmail.com> wrote: > > > > > Is there anything stopping us from enabling Github Discussions for now? > > It > > > seems like we had consensus on that part. > > > > > > On Tue, Apr 16, 2024 at 2:15 PM Matt Pavlovich <mattr...@gmail.com> > > wrote: > > > > > > > Robbie/JB- > > > > > > > > Good calls outs, thanks! I did not mean to skew into contribution guide > > > as > > > > far as I did. I will take a pass at cleaning up. > > > > > > > > Thanks, > > > > Matt > > > > > > > > > On Apr 16, 2024, at 11:56 AM, Robbie Gemmell < > > robbie.gemm...@gmail.com > > > > > > > > wrote: > > > > > > > > > > The security bits are also detailed in all the repositories already > > by > > > > > default at the org level, e.g > > > > > https://github.com/apache/activemq-artemis/?tab=security-ov-file (or > > > > > repositories can define their own policy, e.g > > > > > https://github.com/apache/activemq/?tab=security-ov-file#readme ). > > > > > Though we can of course make references to it clearer. > > > > > > > > > > On Tue, 16 Apr 2024 at 17:48, Jean-Baptiste Onofré <j...@nanthrax.net> > > > > wrote: > > > > >> > > > > >> Hi Matt > > > > >> > > > > >> Imho, we are mixing two topics here: > > > > >> 1. The ticket management system > > > > >> 2. The contribution guide > > > > >> > > > > >> So, let me try to clarify: > > > > >> > > > > >> [PROPOSAL] > > > > >> > > > > >> I'm in favor of GH Issues, but we don't yet have a strong consensus > > > > >> about that. I would propose a new thread about that to give a chance > > > > >> to anyone to speak, and move to a vote. > > > > >> > > > > >> [README/CONTRIBUTION GUIDE] > > > > >> > > > > >> First, ICLA is not strictly required before committership (the > > Apache > > > > >> 2.0 license already covered contributor, it has been discussed on > > > > >> LEGAL Jira). > > > > >> Second, you don't report security issues on a mailing list, you go > > to > > > > >> secur...@apache.org. > > > > >> Explaining how to report issue, create PR, contribute (e.g. > > > > >> contribution guide) is fine and welcome. > > > > >> > > > > >> Regards > > > > >> JB > > > > >> > > > > >> On Tue, Apr 16, 2024 at 5:37 PM Matt Pavlovich <mattr...@gmail.com> > > > > wrote: > > > > >>> > > > > >>> @dev- > > > > >>> > > > > >>> I appreciate all the good feedback and discussion. A number of good > > > > points, suggestions and perspectives. Overall, I see an uptick in > > > community > > > > interest in contributing to ActiveMQ and that’s a great thing! I > > believe > > > > that modernizing the toolkit, reducing contribution friction and > > lowering > > > > load on committers/PMC will help keep the community healthy going > > forward > > > > =). > > > > >>> > > > > >>> I've made a pass at summarizing the points and take-aways from the > > > > [DISCUSS] thread below. Please reply with suggested add/edit/removes. > > > > >>> > > > > >>> [Key community Use Cases] > > > > >>> > > > > >>> UC-1. Issue - User opens an Issue and may or may not intend (or be > > > > able) to produce a PR to address the report. > > > > >>> > > > > >>> UC-2. PR-onl - User opens a PR without an Issue to address their > > > > requested fix. > > > > >>> > > > > >>> UC-3. Security report - User identifies a security issue and needs > > to > > > > report > > > > >>> > > > > >>> > > > > >>> [Proposal] > > > > >>> > > > > >>> Action-1. Enable GH issues and flip JIRA to read-only > > > > >>> > > > > >>> Action-2. Update README in repo to be more of a 'how to engage with > > > > the community' vs a project overview > > > > >>> > > > > >>> > > > > >>> [Update README document to include] > > > > >>> > > > > >>> Update-1. Provide a link for users to create an issue > > > > >>> > > > > >>> Update-2. Provide a link to the mailing list for reporting a > > security > > > > issue > > > > >>> > > > > >>> Update-3. Provide a link for users to submit a CLA > > > > >>> > > > > >>> > > > > >>> [Committer/PMC operating] > > > > >>> > > > > >>> Op-A. For use case #2 where user creates a PR without an issue, > > > before > > > > approval committer/pmc may instruct contributor to provide signed CLA > > and > > > > open a corresponding issue if the complexity warrants. The PR comment > > can > > > > then be updated with the issue id for reference and linking. > > > > >>> > > > > >>> Op-B. Use of GHT Project(s) for planning and tracking Issue & PR > > for > > > > releases. > > > > >>> > > > > >>> Thanks, > > > > >>> Matt Pavlovich > > > > > > > > > > > > >
