theupdateframework / theupdateframework/taps

TAP process: issue with pre-implementation phase visibility

Open
#127 0 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
No language data
Stars
37
Forks
23
PR merge metrics
No merged PRs in 30d

Description

I'm writing down some observations on the TAP process as relative newcomer here, as promised in the community meeting:

The TAP process seems useful: the requirement for a design document and the requirement for a reference implementation for the design both make sense. However, my problem has been that reviewing at least the currently open TAPs has been much more difficult than expected. I feel that a core reason is that the problem definition and idea formulation phases are not publicly visible. TAP 1 does say this:

Each TAP MUST have a champion -- someone who writes the TAP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The TAP champion (a.k.a. Author) SHOULD first attempt to ascertain whether the idea is TAP-able. Posting to the TUF issue tracker, the #tuf channel on CNCF Slack, or the TUF mailing list are good ways to go about this.

but in reality finding these discussions has been difficult.


In the community meeting I compared the TAP process to traditional open source SW development which has two visible phases:

  1. Problem definition phase: Issue/RFE is opened and discussion happens: "is this really a problem?", "what is the root cause?", "what options do we have?", "which option should we choose and why?"
  2. Implementation phase: A pull request of a specific solution is made and reviewed

whereas the TAP process is roughly:

  1. Implementation phase: A TAP pull request of a specific solution is made
  2. Implementation phase: A reference implementation pull request is made

There are still two steps but both are about implementing a specific solution. The problem space and the competing solutions are seemingly never discussed. I'm sure the discussion happened somewhere but unfortunately not seeing it and not being able to refer to it later affects my ability to review the actual implementations: if I don't understand why the initial design choices were made how can I say if the implementation is reasonable?

I don't really want to propose making the process more complex by establishing a specific way to discuss problems/ideas... but maybe someone else has good ideas on this?

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading TAP 1 and comparing its champion and discussion guidance with the currently open TAPs. Review the issue tracker, #tuf CNCF Slack, and TUF mailing list references; a contribution would need an agreed, concrete change to make pre-implementation discussions publicly discoverable, but this issue does not define one.

Written by the indexing model from the issue text.

Assessment

Domain
documentation
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.