============================= MPS Project Regular Procedure ============================= :Author: Richard Brooksby :Organization: Ravenbrook Limited :Date: 2023-03-03 :Readership: Ravenbrook MPS project staff :Confidentiality: public :Status: draft 1. Introduction =============== This is a draft procedure for regular tasks for running the MPS project. 2. Phases ========= This is currently just a brainstorm made on 2023-03-03 with RB, JPH, and PNJ of the things we have been considering each week so far. To be turned into a more useful procedure! Goals: 1. A process that can be operated by anyone at Ravenbrook. 2. A process that can be operated by anyone at all, such as someone who "forks" the entire project. See `this comment on GitHub issue #170 `_. These aren't meetings, but things to get done regularly. - Assigning importances to issues (weekly) - *Always* examine `issues without an importance `_. - They are the input pipeline to requirements on the MPS. - *Always* examine `critical issues `_. - Assign importances with at least two opinions (simplified `Delphi method `__) by considering stakeholders. Having at least two people reduces the chance of missing important requirements that have not been written down. [FIXME: Document importance of having more than one person present and how that reduces the friction on issue creation and flow. RB 2023-03-06.] - Bi-weekly, reviewing critical and essential issues, then optional and nice issues. - `We did observe `__ that this was going to become too much work every week, so we talked about random sampling, looking at least-recently-updated first, etc. - Assign importance to pull requests / branches in progress (weekly) - As with issues, *always* examine `pull requests without an importance `_ and `critical pull requests `_. - *Always* examine `issues and pull requests marked "pending" `_. - Branches are not 1:1 with issues. - When one branch deals with one issue, the importance is probably the same. - The importance assigned to the pull request should be the importance of delivering whatever the branch is trying to do. - Assigning urgencies - Stäkehølder review - See `GitHub issue #182 `_. - What do Configura want? - What do imaginary other clients want? - What do we want? - What we fancy working on is important because if you're doing things you enjoy you'll do them better and faster and in spare moments etc. - What do collaborators want? - etc. [we should have a stakeholder list] - Projects and version planning - Review of existing projects and the version plan - Assigning work (issues and pull requests) to milestones based on urgency and importance - Example projects: - Git Migration is an example - Configura sync: getting them to 1.118 - Activities: setting tasks for the week - What do we have on our plates / which plates we spinning? There's a cost to changing activity. [What GitHub views/queries and mail queries etc. can reveal this? Perhaps we could use an "active" label coupled with assignments? RB 2023-03-06] - Development work - Reviews: all the phases including edit and pi. - Pairing up and group working - The week schedule (using the template) - Assign (or reassign) issues and pull requests - Not well defined yet - People can use a view to see what in their queue, e.g. - People can also just grab things they want to work on - Probably don't assign stuff to other people outside a meeting - Or negotiate it with them - What about e.g. review issues? - Regular reviews (frequency to be determined) [I brainstormed this list on 2023-03-15 based on what I'm aware of and what I've noticed going stale (with consequences) in the past. RB 2023-03-15] - Check key documents - The project page - The repo page (including readme.txt) - The plan - Community documents (contributing, etc.) - Introductory documents (manual, build, etc.) - Licence - Check settings, memberships, and security on sites - GitHub settings - `GitHub MPS repository settings `_ - `GitHub Ravenbrook organization settings `_ - CI settings - See design.mps.ci.service. - CI billing - Keybase settings - Mailing list settings - Ravenbrook web server settings and security - Web site logins for both www and info - Perforce clients that map to web site - Perforce users and access - Git Fusion users and access - Mailing list memberships - SSH logins - what else? - Tools - Compiler releases - Tool status: Emacs, diff, coverage, CI, etc. - Sysadmin - CI logs: Is CI happening correctly? That will check a lot of other things. - Web server error logs - VM logs: Are the LXD and Xen machines running correctly? - Berunda logs - Backups - Mail logs - Cron: Are all the crontabs installed correctly? - Robots, e.g. are they still useful and appropriate? - Mail archive state - Systems software updates - Systems hardware - Something random (e.g. the output of `shuf | head`) - Random file / issue/ pull request / other entity - But within a timebox - Messages - email threads - messaging systems - Business - stakeholder list (including client list) - client milestones and plans - insurance - domains - project accounts - outstanding payments and receipts - staff - wellbeing - holidays - Technology - memory management state of the art - GC state of the art - new languages and old (ML, Lisp) - This list A. References ============= .. [JPH_2023-03-03] "MPS Project Week Schedule"; Jonathan Holburn; Ravenbrook Limited; 2023-03-03; . B. Document History =================== ========== ==== === 2023-03-03 RB_ Created in brainstorm with JPH and PNJ. 2023-03-15 RB_ Adding regular reviews. ========== ==== === .. _RB: mailto:rb@ravenbrook.com