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
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/
>
>
