Hi Matt By experience, Google Doc works fine without need of auth.
I’m totally fine to use GH discussion. That would be a good way to move forward on GH resources ;) Regards JB Le mar. 10 déc. 2024 à 20:20, Matt Pavlovich <mattr...@gmail.com> a écrit : > +1 for the design discussion / document approach vs JIRA. > > -1 on using Google Docs — I’m not in favor of adding yet-another-tool. How > about something like GH discussions? or some other capability already > available to Apache projects. Adding Google introduces a whole new > authentication/authorization/identity system. > > We could then slightly alter the [DISCUSS] process to be — announce on dev@ > via [DISCUSS] subject that a new discussion is taking place on GH > discussions (or whatever other tool) and provide the link. > > Thanks! > Matt Pavlovich > > > On Dec 10, 2024, at 10:59 AM, Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: > > > > Hi folks, > > > > We recently discussed several proposals (SemVer in ActiveMQ, new > > Jakarta Message 3 support in Classic, upgrade Artemis minimum Java > > version, ...). > > > > I would like to propose a "process" to: > > - discuss "long" designs > > - track proposals > > - facilitate collaborative contributions > > > > The process proposal is the following: > > - the contributors work on a design proposal. This document should: > > a. provide a rationale and what problems are solved > > b. provide abstract design with context > > c. clearly describe design options with implementations details > > (optionally pseudo code) > > The document is a Google Document, where anyone can comment. > > - the Google Document link is attached to the corresponding Jira. The > > Jira should have the "proposal" tag. > > - the Google Document link is sent to the dev mailing list (with a > > quick description of the proposal) > > - If needed, the Google Document "leader" can schedule a meeting > > (Google Meet) to discuss details and clarify design options. This > > meeting should be recorded (or at least notes should be taken). The > > design document should be updated after the meeting, and the meeting > > notes should be shared either to update the design document or on the > > dev mailing list. > > > > It's a process used in several Apache projects (Apache Iceberg, Apache > > Polaris, Apache Arrow, ...) and it works pretty fine. > > > > Thanks to that: > > 1. we can track all proposals Jira we have (basically populated our > roadmap) > > 2. before implementing, we can collaborate on design using the Google > Document > > 3. we should have a better collaboration, especially on complex > > design/implementation > > > > For instance, I would like to illustrate the process with Jakarta > > Messaging 3.1 Shared Subscription. We know this feature is not trivial > > and requires a clean design before rushing on the code/implementation. > > So, we can start with a design Google Document, attached to > > https://issues.apache.org/jira/browse/AMQ-8323 and send the design > > document on the dev mailing list. > > Then, we start contributing to the document, adding comments with > > questions or suggestions. > > The purpose is to reach a consensus on the design before actually > > starting the implementation. > > > > Thoughts ? > > > > Regards > > JB > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org > > For additional commands, e-mail: dev-h...@activemq.apache.org > > For further information, visit: https://activemq.apache.org/contact > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org > For additional commands, e-mail: dev-h...@activemq.apache.org > For further information, visit: https://activemq.apache.org/contact > > >
