Jayant Saxena via Mailman-Developers writes: > started exploring the Mailman 3 repositories on GitLab to > understand the architecture and development workflow.
The best guide to this is the dev docs: https://docs.mailman3.org/projects/mailman/en/latest/ In the sidebar, the "theory of ops" stuff starts at the Contributing to Mailman entry, which speaks to the development workflow and is followed by a number of essays on architecture and implementation methods. There's also a chapter by Barry Warsaw in "The Architecture of Open Source Applications, Vol. II, Ch. 10". Some of these materials are more than a decade old. but the architecture has been remarkably robust. (Maybe not so remarkable, a lot of the ideas we use go back to the 1980s or even 1970s, and the Zope 'interface' framework which is used to ensure that implementation tracks the specification goes back to the late 1990s and have proved themselves.) > I would appreciate guidance on beginner-friendly issues or areas > within Mailman Core or related components where new contributors > can start contributing effectively. Direct contribution, very valued by mentors! ;-) 1. Review others' merge requests. You will never be as good at reviewing your own code as you are for others', but it's the best practice for getting your code in good shape for merging. It's a contribution even non-coders can make, like "Uhhhm, that isn't going to work like you think it does, it's going to be more annoying to users like me than it's useful to you." Code contribution, more fun for you but remember, developers who like to code are a three shots for a quarter, take best of three. You do have to get at least one MR approved and merged to prove you can navigate the contribution process, but that can be a typo correction in a comment. 2. You can filter on "easy" and "beginner" tags in the GitLab issue database. "Easy" means "easy to diagnose and few lines of code required", while "beginner" means "you can address this issue with the description in the issue and knowledge of Python". More effort for the results, indirect contribution (makes other developers' lives easier, doesn't affect users much). 3. Checking the old MRs, whether the issue they intend to address is still present, whether they still do what they claim if the merge still applies. Recommend closing (in a comment or on this list) with "fixed" or "won't fix" when that seems approriate. 4. Collapse the threads view so that you see only the root titles.[1] Browse those in the Mailman Users' list (on lists.mailman.org, not python.org). If you find what looks like an interesting issue, read some of the discussion. If you are interested, search for corresponding issues in GitLab. If there are none, add one. If you find more than one, check that they cross-reference each other. If you think some are duplicates, merge them (usually this means choosing the best-written and most complete, and adding any random facts or ideas from others, sometimes it means treating near-duplicates as subissues and creating an umbrella issue, adding cross-references to all). Hope this helps. Footnotes: [1] I use my own archives so I'm not that familiar with HyperKitty, but I think you can. -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan _______________________________________________ Mailman-Developers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/mailman-developers.python.org/ Mailman FAQ: https://wiki.list.org/x/AgA3 Security Policy: https://wiki.list.org/x/QIA9
