+1 for the proposal. Using a centralized tool for documenting the design would be excellent. This could be Google Docs or Confluence (Atlassian), provided we have access to it through Jira.
I also support the proposed design document template. While we shouldn’t be overly prescriptive, the document leader should be prepared to address additional questions, such as design limitations, maintainability, and so on. I appreciate that we are not mandating the recording of meetings. It’s important to allow the document leader and attendees to decide whether they are comfortable with recording. However, the document leader must ensure that meeting notes are documented. Best regards, Samir -----Original Message----- From: Jean-Baptiste Onofré <j...@nanthrax.net> Sent: Tuesday, December 10, 2024 8:59 AM To: dev@activemq.apache.org Subject: [EXT] [PROPOSAL] Discussing design/proposals process CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le contenu ne présente aucun risque. 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
