Re: Old directions in social media.

["Deen, Glenn (NBCUniversal)" <[e-mail]>]

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