Re: Old directions in social media. - Issue trackers

"Joel M. Halpern" <jmh@joelhalpern.com> Tue, 05 January 2021 19:17 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918D73A11A0 for <ietf@ietfa.amsl.com>; Tue, 5 Jan 2021 11:17:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.382
X-Spam-Level:
X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.262, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXRK17x4sxi4 for <ietf@ietfa.amsl.com>; Tue, 5 Jan 2021 11:17:32 -0800 (PST)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EEA63A119A for <ietf@ietf.org>; Tue, 5 Jan 2021 11:17:28 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4D9Mh800qdz1nvXX; Tue, 5 Jan 2021 11:17:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1609874248; bh=JrzODptR3CIBxNpttcbaT/hb/E/GY2YIBqEcmrdGjbM=; h=Subject:To:References:From:Date:In-Reply-To:From; b=pKdZo0/hhuahafrNurIJBm+3ISpwlhRlOlZln4ntEwhug8mbzixQMR/k3kvbno4vA T5+/e0wekIFjafAndyzGA/CXyYdfTm7a9GMhKa6D82hqOe3YcVYZBWO9jOEkpOlhSo l9IuTpXkvuufJXH4jLbUw4Kq9QejiVA621LRmjXw=
X-Quarantine-ID: <q9xxki0mjh8G>
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4D9Mh73FnRz1nvYK; Tue, 5 Jan 2021 11:17:27 -0800 (PST)
Subject: Re: Old directions in social media. - Issue trackers
To: "Deen, Glenn (NBCUniversal)" <Glenn.Deen@nbcuni.com>, IETF Discussion Mailing List <ietf@ietf.org>
References: <07DC5B1D-7B79-422B-BABC-C6A124359C88@nbcuni.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <3ba06742-1102-984b-dc78-960c33a46027@joelhalpern.com>
Date: Tue, 05 Jan 2021 14:17:26 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0
MIME-Version: 1.0
In-Reply-To: <07DC5B1D-7B79-422B-BABC-C6A124359C88@nbcuni.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/C5N8q5R8mrXz0f8A_HmMPad_ZeA>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Jan 2021 19:17:35 -0000

I agree that for contentious WG documents, issue trackers are extremely 
useful.  And something better than the one we have in the IETF tools is 
desirable.  I do not even object to using git based issue trackers.  As 
long as the discussion is visible and understandable (yes, I am 
repeating myself) on the email list.

Yours,
Joel

On 1/5/2021 1:59 PM, Deen, Glenn (NBCUniversal) wrote:
> There's a lot about git/github that I'm not a fan of.  The sometimes jarringly weird terminology it uses overly complicates new users learning it, even those experienced with code management systems such as SCCS, CVS, and SVN.  I can't begin to image the terrible barrier it presents to those who don't come from that background.
> 
> The situation isn't as simple as stopping using github and fall back to the good old days of just mail lists.
> 
> There is a real need for something better than email lists in doing to document development and having WG discussions, especially now that we don’t meet in person, and it's impacting the productivity of many the IETF's WGs.    That is the driver, and not just the desire to use something new and shiny, is what is motivating many groups to try using Github.   Even if we stopped using Github, the functional needs wouldn't disappear.  They would continue on and would simply motivate people to try using other tools to satisfy the current need.
> 
> A good example is management of issues.    Issues are very hard to manage under mailing lists, especially as the number of participants and the number of issues grow.    Some participants conflate issues together under a single thread, other participants spread a single across multiple threads often with very difficult to follow context due to different styles of mail quoting or writing, and there's most often no clear capture of the issue's resolution.    It results in issues getting lost, dropped, and rambling discussion with points being repeated and repeated, and many participants being put off participating because they feel they've lost the thread of current issues and give up and stop engaging.
> 
> The current limitations of managing issues via only mailing lists negatively impacts the IETF's efficiency.  I believe also pushes away new contributors to the IETF work since for every seasoned IETF'er who through years of experience thrives in the current mailing list environment, that same environment is a great barrier to entry for new comers that are themselves better versed in other workflows, tools, and terminologies.
> 
> That's why groups have been drawn to github.  It provides issue management which, although it can be very confusing  and of putting due to the terminology to many,  is better than nothing at all.    However, while that's the current choice that is on the table, it doesn't necessarily need to be the only choice long term.   If we could identify the functional needs then we can use that in selecting or developing an alternative that provides the needed functions.
> 
> 
> Useful to WG work, from any tool,  are the ISSUE/Change Request features:
> 
>      (1) Trackable issues and discussion comments (aka github issues) - along with a classification taxonomy scheme that can be tailored to the project;
>      (2) Trackable change request submissions (aka pull requests) that incorporate comments and discussion;
>      (3) Clear closure/resolution states (aka.  Accepted/rejected/closed) that are captured and documented for both ISSUES and for Change Proposals.
>      
> 
> 
> I'm no fan of Github for it was and still is a learning curve I've had to climb despite a long history working with pervious systems.   It's why for the ADD group I felt the need to write the ADD WG Github primer (https://github.com/ietf-wg-add/wg-materials/blob/master/Using%20Github.md).
> 
> If there was an alternative toolset that could provide the 3 above issue management features then there would be an alternative.    For instance in the past I've used Bugzilla as a companion tool for managing collaborative work as it provided the above functions, but that's a tool of the past not something I'm proposing for today.
> 
> If there was a tool that provided the 3 issue features,  didn't require a new vocabulary to be learned by WG participants, and could cross integrate with the IETF's existing process of mailing lists and datatracker, we'd have something that would advance and improve WG work tremendously.
> 
>   If these features were also available via APIs that would allow integration with modern development tools that would enable participants who preferred different tools to also participate without needing to leave the comfort of their current toolset.
> 
> There are no doubt additional requirements.  The above 3 features are just a set of issue/change request features that the current mailing lists/datatracker tools don't provide.
> 
> 
> -glenn deen
>