On 8/2/19 1:49 PM, Brian E Carpenter wrote:
> Mark,
>
> On 03-Aug-19 05:14, Mark Nottingham wrote:
>> My experience is very much the opposite. It's easy to lose a bit of feedback in a tumult of e-mail; threads don't have any formal closure unless you impose an unrealistic amount of structure onto mailing list discussions.
>>
>> In contrast, using an issues list forces you to make a deliberate decision about the fate of a particular bit of feedback; if the person raising it disagrees with the disposition of the issue, they can complain there, to the mailing list, or to the chairs directly.
>>
>> In other words - issues have explicit states ("open", "closed"), owners, and tags ("editorial", "design"). In practice that I've seen, this means that issues get more scrutiny, and there is more accountability -- not less.
>
> I fully agree that an issues list is necessary when things get complicated. But IETF rules
> *require* consensus to be formed on the mailing list. That creates a bit of a problem
> for any issues list technology, not just GitHub. So far, I haven't seen a perfect
> solution.
>
> I made up a solution a couple of years ago, which needed no extra technology:
> https://tools.ietf.org/html/draft-ietf-anima-grasp-15#appendix-A
If I understand correctly in that solution the appendix contains a snapshot of the open and closed issues.
As I-Ds are actually kept forever, I think that's a great idea to use that as a way to document the development process of a standard.
In fact I would (and probably will) store all the discussions from the previous draft until that draft (i.e. replacing completely the appendix from the previous draft) in the appendix:
- For all *external* discussions, copy the whole thing (that can be automatized for GitHub, GitLab, etc...)
- For *internal* discussions (basically emails, jabber, minutes, audio and video recording), just store an url to that piece of data.
This way we create an immutable record of the creation of a standard without changing the process. And as it is an appendix at the end of the document which is anyway removed before publication, it does not matter if it is multiple 100s of pages long.
--
Marc Petit-Huguenin
Email: marc@xxxxxxxxxxxxxxxxxx
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug
Attachment:
signature.asc
Description: OpenPGP digital signature
