[Python-ideas] A bit meta

[Ian Lee]

So with the upcoming move to GitHub of the CPython repository, planned with PEP-512 [1], what about the idea of creating a Git repository on GitHub to serve as a replacement for a mailing list, for example python-ideas? Such a repo might be hosted off the “Python” GitHub organization: https://github.com/python/python-ideas 

> On Jan 29, 2016, at 20:35, Guido van Rossum <guido at python.org> wrote:
> 
> What I like most is that the site encourages the creation of
> artifacts that are useful to reference later, e.g. when a related
> issue comes up again later. And I think it will be easier for new
> folks to participate than the current mailing list (where if you don't
> sign up for it you're likely to miss most replies, while if you do
> sign up, you'll be inundated with traffic -- not everybody is a wizard
> at managing high volume mailing list traffic).

Such a repository could address a number of items brought up above, including providing a permanent link to artifacts: comments and threads (issues in the issue tracker). The ability to watch the entire “repo" (mailing list) and unsubscribe to “issues” (threads) that are no longer interesting to a watcher (similarly to the way “muting” works in Gmail). Or vice versa, have notifications off by default and able to opt into notifications if something interesting catches your eye.

Additionally, this would provide a straight forward and pretty easy way to link discussions to actual changes other repos in an easier way that something like “CPython at commit XYZ123”. 

Stephen J. Turnbull writes:

> On the other hand, one attribute that you have mentioned (the ease of
> finding issues) has a useful effect.  To the extent that StackExchange
> makes traffic management easy (specifically filtering, threading, and
> linking), it might encourage users to follow links to other threads
> where relevant discussion is posted.  In the thread where Antoine
> spoke up, the fact that the discussion that led to the main decision
> was on python-committers almost certainly had a lot to do with the
> fact that most of the posts were unaware that the main decision was
> final, and of the reasons for and against the decision that had
> already been discussed.  And those reasons were rehashed endlessly!  A
> forum that encourages retrieval of previous discussion before posting
> would make a big difference, I suspect.  Eg, one with a check box "I
> have read and understood the discussions cited and I still want to
> post"[4] for comment entry and a "No! He didn't do his homework!"
> button next to the posted comment.<wink/>

A lot of the filtering, sorting, and other benefits that Stephen mentions would be available through GitHub’s searching capabilities, and others such as tagging of “issues" (mail threads) with labels (peps, new feature, duplicate, change existing functionality, etc come to mind).

Additionally, an issue / thread in the repo could be “closed” when it is off topic, with future issues opened being able to be closed, marked as “duplicate” and linked against the old closed issue to try to provide that bit of history without needing to take as much time to re-write the response.

Other benefits include syntax highlighting, markdown formatting (which was announced this week [2]), and ability to interact with the thread via email (replying to the email creates a comment on the issue) or through the browser (which is nice for the presumably small, but at least >= 1 population that have their personal email blocked by their corporate firewall). 

I could also see their being a lot of benefit in making the actual code in the repository to be things like contributing information, what is appropriate to say / ask on each list, etc. For lists like core-workflow I could even see this evolving to where the “Code” was a GitHub Pages [3] page that actually hosts directly something like the contributor guide (which could still live at whatever URL was desired, while letting GitHub do the actual hosting. Extra benefit is that it provides a very straightforward way to update some of the developer, contributor, and mentoring guides.

It doesn’t “solve” some of the other issues such as voting, reputation of a user, etc, However, I’m not hearing a resounding desire for those anyways.

There is at least *some* precedent for this in the form of the Government GitHub [4][5] community and related agencies such as 18F [6]. The former of which has a “best practices” repository [7] which serves this same purpose of communicating and discussing ideas, without necessarily being a code repository. Unfortunately, that repository is a private repository and requires a government email address and joining the “government” organization to access; see [8] for details on joining if you’re interested. 

[1] https://github.com/brettcannon/github-transition-pep/blob/master/pep-0512.rst <https://github.com/brettcannon/github-transition-pep/blob/master/pep-0512.rst>

[2] https://github.com/blog/2097-improved-commenting-with-markdown <https://github.com/blog/2097-improved-commenting-with-markdown>

[3] https://pages.github.com

[4] https://government.github.com/ <https://government.github.com/>

[5] https://github.com/government <https://github.com/government>

[6] https://github.com/18F/ <https://github.com/18F/>

[7] https://github.com/government/best-practices <https://github.com/government/best-practices>

[8] https://github.com/government/welcome <https://github.com/government/welcome>

~ Ian Lee | IanLee1521 at gmail.com <mailto:IanLee1521 at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160130/76c02f0a/attachment-0001.html>