TAP process (TAP 1)

[joshuagl]

I think the TAP process could use some clarification/modernisation. The following is a list of questions that arose whilst reviewing TAP 1.

• Per TAP 1 the Final state is when the features of a TAP are integrated/implemented within the reference implementation. There is no mention of integration into the specification. Should there be an additional state for "in the spec" vs "in the reference implementation"? Or should Final be "in the spec"?

• Should TAP formats recommend line-wrapping? The existing TAPs mostly seem to line wrap at ~72-79 characters.

• Is Post History, and the mailing-list centric nature of TAP 1, still relevant? It seems to me that it makes sense to discuss TAPS here, on GitHub, with posts to the mailing list to draw interested parties into the discussion? TAP 1 suggests that TAP submissions, reviews and ownership transfers should happen on the mailing list. I haven't seen that happen in practice.

• TAP 1 suggests that

  If there are multiple authors, each should be on a separate line following RFC 2822 continuation line conventions.

  that doesn't appear to be true in any of the current TAPs. Should we update the TAPs or change the guidance in TAP 1?

• A TAP is accepted as a Draft, but there's also an Accepted status. It's not clear to me from reading TAP 1 when we are talking about accepted as Draft and accepted as Accepted. The statuses and how a TAP moves through them should be cleared up.

[joshuagl]

• Per TAP 1 the Final state is when the features of a TAP are integrated/implemented within the reference implementation. There is no mention of integration into the specification. Should there be an additional state for "in the spec" vs "in the reference implementation"? Or should Final be "in the spec"?

I absolutely agree with the rationale that the complexity of a TAP may not become clear until someone has tried to implement it, and therefore agree that no TAP should be accepted (Accepted?) until there's a reference implementation.

My impression has been that what makes a TAP Final is its inclusion in the specification, as that is the TUF artefact that more people are using and engaging with.

My current thought is that a TAP should not go from Draft->Accepted until there's an implementation, but that a TAP moves from Accepted->Final once it's integrated into the specification.

Merging into the reference implementation should follow swiftly, so long as we care about maintaining compatibility with the specification.

[trishankatdatadog]

Thanks for raising these questions, Joshua! One concern of mine in particular is whether we should (or can we?) updated TAP 1 to include RFC 2119 language...

[joshuagl]

Thanks for raising these questions, Joshua! One concern of mine in particular is whether we should (or can we?) updated TAP 1 to include RFC 2119 language...

I think we SHOULD use RFC 2119 language. In part because using RFC 2119 definitions can make the intent clearer and in because we use that language in the specification and doing so in TAPs may make their integration into the specification easier.

[trishankatdatadog]

Thanks for raising these questions, Joshua! One concern of mine in particular is whether we should (or can we?) updated TAP 1 to include RFC 2119 language...

I think we SHOULD use RFC 2119 language. In part because using RFC 2119 definitions can make the intent clearer and in because we use that language in the specification and doing so in TAPs may make their integration into the specification easier.

Yes, makes clear what is nonnegotiable or not

[joshuagl]

Another question to consider, do we expect links to the augmented reference implementation to remain valid? i.e. tap4 links to a branch on GitHub which no longer exists, so anyone following the link gets a 404.

[JustinCappos]

I think we should fix these. Justin

…

On Fri, Jul 10, 2020 at 10:29 AM Joshua Lock ***@***.***> wrote: Another question to consider, do we expect links to the augmented reference implementation to remain valid? i.e. tap4 links to <https://github.com/theupdateframework/taps/blob/master/tap4.md#augmented-reference-implementation> a branch on GitHub which no longer exists, so anyone following the link gets a 404. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#121 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGROD7CATCOOBFME4MBFUTR24QV7ANCNFSM4OUOZZRA> .

[joshuagl]

I just merged #124 which overhauls the TAP 1 process document.