Brian,
> On 2 Aug 2019, at 1:49 pm, Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> 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.
I think "formed" is stated too strongly; we often "form" consensus in a meeting, and confirm it on-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.
If we hold perfect as a bar to using something, we won't get anything done; as many have pointed out, both in-person meetings as well as mailing lists are far from perfect.
Cheers,
>
> 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
>
> Brian
>
>>
>> Cheers,
>>
>>
>>> On 2 Aug 2019, at 4:35 am, Rich Kulawiec <rsk@xxxxxxx> wrote:
>>>
>>> On Wed, Jul 31, 2019 at 08:43:42AM -0400, Keith Moore wrote:
>>>> IMO it is dangerous for IETF to be dependent on an externally-run platform
>>>> that is subject to change at a whim.
>>>
>>> I strongly concur with this. The IETF should run its own repository,
>>> subject to its own policies/procedures/etc. Yes, that's more work,
>>> but it assures autonomy and it's much less work than frantically
>>> trying to adapt to a sudden change imposed by an external platform --
>>> whose agenda is not the IETF's agenda.
>>>
>>> ---rsk
>>>
>>
>> --
>> Mark Nottingham https://www.mnot.net/
>>
>>
--
Mark Nottingham https://www.mnot.net/
