Management process for Arti client deliverables/features

For development of Arti client, we got a grant from the ZCash foundation. This is the way we are deciding to work in Gitlab to track the work.

• Version numbers have NOTHING TO DO WITH milestones or deliverables for the ZCash grant project.

• We continue to use Doing, ~Done, Backlog, Roadmap::Future, Backlog, labels for priorities (the same as for other projects for the team).

• Milestones represent rough areas of work (often, features or areas of feature) (not necessarily features from funders); every feature-related ticket is in a milestone whether it is "should" or "must".

• Milestones will NOT correspond to versions. Therefore there may be multiple releases of the software with successive versions, containing work towards the same milestone (or towards several milestones)

• Milestones will NOT correspond 1:1 to funded deliverables.

  • They may resemble funded deliverables and often will. When a milestone resembles (approximates) a funded deliverable, the milestone tagging in gitlab can be used as part of grant/estimation work. However, estimation must also look at tickets tagged with the *-must label for the deliverable (see below).
  • The arti team uses the milestone to organise our work, and in particular, to see what work is outstanding for a particular feature. We use the milestone as one way of finding out what ticket we should work on next.
  • We will not use the gitlab start date and due date features for milestones. The expected completion date of either a milestone, or a funded deliverable, or a feature, will be estimated by other means. (IOW, milestones are just classification)
  • A milestone counts as "completed" when we say "this area of work is 'done enough' to say so to the users." At this point we (the arti team) close the milestone. We close tickets or move them while doing this. In theory this would correspond to all the *-must tickets for that milestone but in practice that will not correspond precisely, particularly as an area of work nears completion.
  • The milestones will be, for now:
    • Onion services
    • Onion services security
    • Client feature parity
    • Guard security.
    • RPC

  Alex notes after the meeting: All of these are created for tpo/core/arti now.

  • The meaning of a milestone like "Onion services" is "these tickets are related to onion services". It can also be "this would be a good/reasonable thing to do as part of onion services." But it does not mean "we cannot call onion services done unless every ticket here is done."

  • As part of the meetings we have, we will go over milestones and look if we think this feature is done; the remaining tickets will be lifted out and potentially be left without milestone for future pick-up, ~First Contribution, etc. (these will all be things that clearly wasn't needed to do anyway).

  • If a milestone is too big, we can split it after conversations in a meeting. Eg, we could make an RPC milestone.

  • There are must labels for each particular funded deliverable. (or feature?) (eg "onion-service-must" "rpc-must")

    • must labels will be approximately:
      • {milestone}-must, for each milestone
      • A "{milestone}-must" label means "we don't think that this milestone can possibly be closed without doing this work (or at least deciding that it is not necessary.)"
      • A ticket may have SEVERAL *-must labels.
        • onion-service (meaning "onion services work but aren't necessarily secure")
        • onion-service-security (meaning "onion services work and are secure" would be meanings of labels")
        • rpc
        • client-parity
        • guard-security
      • There is a "must" label for each milestone.

    Alex notes after the meeting: All {milestone}-must labels are created.