theupdateframework / theupdateframework/taps
TAP process: issue with pre-implementation phase visibility
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:
- 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?"
- Implementation phase: A pull request of a specific solution is made and reviewed
whereas the TAP process is roughly:
- Implementation phase: A TAP pull request of a specific solution is made
- 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
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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