Define roadmap and policies for maintaining the project

[rdimitrov]

Hey, everyone 👋

In the past few months, there have been quite a few improvements, bug fixes, and new features added to the go-tuf project - i.e., support for targets delegation, automated release process, CLI improvements, and much more. Thank you all for contributing to this 🎉

In that sense, I want to initiate the discussion of a few topics that will be of benefit to the project too -

1. Policies that will help maintain and improve the overall quality of go-tuf

• Contributing guidelines - i.e., expected PR/commit styles, passing CI, docs/tests being added/updated for new features, a process for submitting security vulnerabilities, etc.
• Maintainer guidelines - i.e., define a review checklist, a minimum number of approvers before PR can be merged, issues that people are working on should be part of the roadmap plan and have owners assigned which indicate their commitment, define and promote the use of labels, avoid having stalled PRs and Issues, Etc.

2. Project roadmap

• This was raised several times, but now that go-tuf is more mature it becomes more challenging to introduce new changes as they might end up overlapping or even blocking one another.
• Having a roadmap would help the project a lot in aligning everyone's efforts and it will also promote transparency about the overall direction of go-tuf.

Goals:

The plan is to start by -

• Creating a few drafts PRs of the guidelines where we can discuss hands-on their content
• Together come up with things we'd like to see listed in our roadmap and have them sorted into categories, like "Must have", "Should have" and so on. See the the MoSCow method for reference.
• While doing that, bootstrap an initial plan in the "Projects" tab for go-tuf. My thoughts are to start by having a simple plan for the next possible release, for ex. v.0.4.0, where we can put tasks we would like to see covered - i.e., define a roadmap, add tests for X, add feature Y, etc.

I plan to volunteer and try to address these several bullet points in the next couple of weeks. In that sense, it would be really helpful to sync and have some input, so please feel free to share any ideas/suggestions that we can discuss and incorporate from the start 👍 Thanks in advance!

[znewman01]

Awesome, thanks for taking the lead on this @rdimitrov 👍

Miscellaneous thoughts, not very organized (sorry!):

• IMO, if it's difficult for drive-by committers to get up to speed, get tests passing, good test coverage, etc. that's a symptom of a deeper problem.
  • We don't want to lower standards in those regards at all, but I'm not terribly comfortable with the burden that we're placing on new contributors right now.
  • A new contributor should be able to come, add a feature, add a test (easily!), run the same checks as CI locally, and push, and then both we and the contributor should be confident about merging that PR.
  • Similarly, it feels unfair to ask a new contributor to have extensive docs, etc. for a PR if the surrounding code has no documentation, especially because it's so much easier to know what to write if you have similar examples.
  • I've had a lot of experiences where I wanted to come in and fix one quick thing, but existing tech debt means I need to fix something else first (see test: Update Python interop tests to python-tuf v1.0.0 #228)
  • Similarly, I have some amount of fear when making changes that I'm going to break something
• Relatedly, I think one of the v0.4.0 milestones should be a quality drive
  • Before we commit to new contributor standards, we should make sure that the existing codebase meets those standards (not 100% necessarily, but at least gesturing in the right direction).
  • To that end, I think testability is a huge problem with the codebase as it stands. I don't know that I have a specific ask here, but right now we have a lot of "instantiate a thing, and then do a whole bunch of miscellaneous operations with it because instantiating requires so much boilerplate" tests, which often feels like flailing. I'd like to see that migrate towards many tests of specific scenarios/properties, with a purpose.
    • The mere existence of tests: create unit tests for verifying the protection against rollback attacks #286 suggests testability issues: in a healthy codebase, it should be easier to write a quick test to reproduce the issue than to fix the bug.
  • Similarly, a docs drive could make a huge difference in a moderate amount of work.
• Tech wishlist (themes: testability and code health, setting ourselves up for greater velocity moving forwards)
  • Formulate a consistent canonicalization strategy #261
  • disentangle the keys database from the repo implementation (see also client: Clean-up the use of a database to keep client state #219)
  • Refactor LocalStorage to be interoperable for both repository and client side #225
  • I still owe you Implement TAP-12 for future-proofing #232 and interop tests use deprecated python-tuf code #221
• We can put bigger features on the longer-term roadmap; I think focusing on these up-front will help a lot.
  • I'm quite interested in re-examining the API/CLI design—the new python-tuf implementation has some nice abstractions that we may want to mimic.
  • And then we can do more fun/big stuff!
• Process wishlist
  • I think docs: Add contributing guidelines for go-tuf #190 is pretty close to what we want, I'm on-board for "launch and iterate" there

[joshuagl]

Thank you both for the great ideas here. I really like the prioritisation of new contributors, especially as the proposed changes will all be super useful for existing contributors too!

I like the idea of creating a roadmap with three buckets (contribex, code health, testing) and some concrete actions within them (issues above) to focus priorities for the next period (half year?).