On Sat, Aug 13, 2016 at 12:26 PM, Brett Cannon <brett(a)python.org> wrote:

In monitoring the typeshed tracker, I wanted to get some help with some of the mechanics and details of creating type annotations. After searching awhile and finding nothing, I finally added a comment to an existing GH issue. Guido responded to just use the GitHub issue tracker.

I still haven't opened a thread there to ask for any help (got a bit distracted away from typeshed, for one thing), but it's still a bit non-obvious to me how well that would work for the typeshed use (or as a discussion forum for other topics like the overload-sig). For example, how good is the search functionality?

As good as Google or Bing can be. :) In all seriousness, I have found the GitHub search box like any other search box that does word matching, but GitHub issues are indexed by the major search engines so you are not wholly at the whim of GH.

If someone comes looking for X, how likely is it that they won't find anything, and wind up opening a new issue which has been rehashed before?

Probably no more often than they already do on any other mailing list that doesn't even have a search box.

How hard will it be for moderators to redirect rehashed topics back to old issues?

Easy: you link to it (w/ GH shorthand) and then close the issue (could even have a label to mark it a duplicate if you want).

Will they be able to quickly close down diversions?

No one has solved that and once again it won't be any worse than the status quo.

How hard will it be to split a sub-topic comment into its own issue, with a reference back to its parent?

By thread or comment? The former there is GH shorthand in the Markdown, for the latter there is a link you can use.

In short, will moderators still have to basically read everything to make this all work?

No worse than what our status quo is, but at least moderators will actually have the option to close discussions unlike on a mailing list. -Brett

I have often likened Wikis as a "bag of pages". It quickly becomes an unordered mess of stuff, and requires someone with fairly good skills to organize a wiki so at least at the top level it has some meaningful structure. How might an issue tracker be wrangled into something more than a "bag of issues"? (I suppose this question applies to all the proposed tools. Whoops. sub-topic alert. <wink>)

Skip

On Aug 16, 2016, at 7:18 PM, Barry Warsaw <barry@python.org> wrote:

On Aug 13, 2016, at 08:14 AM, Guido van Rossum wrote:

...

I think it would be beneficial to use GitHub issues instead, one for each topic and perhaps one for general notifications like announcing new topics or forum wide announcements.

I'm *really* skeptical about using trackers for general discussions. Even for trackers I like (e.g. Roundup and Launchpad), any long discussion with lots of back-and-forth is simply too painful to follow. I can't delete or ignore the comments that aren't germane, obsolete, unhelpful, or misleading. I have to continuously scroll back and forth, or even worse, follow next-page links to refer back references. And searching for the key insight or message isn't easy ("Now, where did Guido semi-pronounce they way he wants it to work? And where did Raymond disagree?" :).

We *sort of* use Github issues on Warehouse and pip for this. Every once in awhile we’ll take it to our ML, but the vast majority of things get discussed on github issues (and for Warehouse, there isn’t even a mailing list). Larger cross project things do tend to go to distutils-sig. This generally works but I feel like it’s a bit of a square peg into a round hole and that it’d be hard to scale up to a list of a larger size. — Donald Stufft

On Aug 17, 2016, at 06:29 PM, Stephen J. Turnbull wrote:

We have a tracker and it's used a lot. If people wanted to have these discussions on the tracker, they could, but in fact (1) linear "ok, let's implement this thing!" subthreads *do* often move from lists to the tracker, and (2) "uh, there are ramifications ..." subthreads do move in the opposite direction. I conclude there seem to be reasons why these discussions require a separate channel from the tracker issues themselves. (That doesn't mean that the separate channel can't be a tracker itself.) I don't know what those reasons are, though.

These are great observations, and it's clear (to me at least ;) that no one channel is really appropriate for *all* discussions. Maybe that's obvious. When you know what you want to do, but need to hash out the details of how to get it done, e.g. fix a bug, implement an accepted PEP, the linear nature of trackers and code review tools work great. When there's no consensus, or there's more uncertainty or cloudiness in what needs to be done, a more freewheeling forum generally feels more right (whether it works better or not is a different discussion!).

The problem with type (2) threads is that once they move on to the ML, the focus on a single controversial issue is typically lost, and people (repeatedly) bring up already decided objections and proposals.

I'll note that this was supposed to be one of the purposes of a PEP. By capturing the decisions and the rationales behind those decisions, even if there are still open questions, it was hoped that a PEP could shutdown those diversions. One problem I think is that even once a decision is made (on a sub-point if not the whole feature), people will still disagree and feel the need to re-justify their disagreement. Similarly, the trend to generalize a feature leads to many detours. "Oh, if you only tweaked this argument, then this feature could also be used to...". Can any technology limit the burnout induced by such social effects? Are such tendencies always bad?

How about, instead of "you must be this tall to post", we put a condition "you must be nosy on the tracker issue to post" (implying that you've read the thread, not merely checked a box, of course)? That will not eliminate attempts to reopen objections and proposals, but it might reduce the number of completely gratuitous and redundant comments sufficiently.

That's a very interesting idea. A recognition that both trackers and mailing lists play a role, and better integration between the two could lead to some interesting patterns. OTOH, I don't know about you, but I can't keep all the details of all the issues in my head all the times. I often have to go back and re-read a tracker issue, or PEP, or discussion thread if I'm re-engaging with a topic after some time away. Or if I'm just stumbling on something interesting that I thought was uninteresting before. This leads to...

...

I can't delete or ignore the comments that aren't germane,

Deleting in a shared resource is obviously not going to happen. But muting is a matter of an element id in the DOM and a couple lines of Javascript. If only we had 6 million dollars, we could rebuild this man! (This is where "proprietary" comes into play, though. :-( )

Right, "muting" is the better term for hiding things *I* think are unimportant, or are dead ends in a particular discussion. When the thread is largely in my inbox (a bad thing), I can keep just the few messages that need more thought, or more time to respond thoughtfully. More and more I find myself going to Gmane and marking the important messages in a thread in my MUA, effectively muting the rest. It sure seems like there's *something* important in that observation.

...

obsolete, unhelpful, or misleading. I have to continuously scroll back and forth,

Sometimes, yes. But remember, Guido has a model in mind where we encourage linear discussion that proceeds by refinement. If we can pull that off, convergence should happen rapidly, and long rambling threads should be relatively unusual. The mute-message and mute-subthread features should also reduce the amount of traversing.

Agreed, at least for discussions that can proceed linearly (see above).

@Barry: regardless of where Python goes, I want this in HyperKitty!

Oh yes!

...

And searching for the key insight or message isn't easy ("Now, where did Guido semi-pronounce they way he wants it to work? And where did Raymond disagree?" :).

How is that easier in an MUA? Is it just a function of owning the mail folder so you can delete or archive junk, or select important stuff into a separate folder, thus shortening and organizing threads? Or having a private tagging function?

More important that owning the mail folder (i.e. Gmane), it's owning my own metadata about the thread. My MUA allows me to mark important messages, maybe with a color or other tag, and I can very easily search for an author, date, subject, or other metadata either locally or inherent in the message. It's not perfect though, and I could see where having the ability to add personal, custom metadata to HK threads would be really useful. It's also harder to mute individual messages in a thread in my MUA, though it's very easy to mute entire threads I don't care about. This feels like an important insight. The messages I think are important will be different than the ones Steve or Guido or Brett think are important. The people or points I agree with will be different again. Having a way to control what *I* care about independent of anybody else is the best way for me to participate in a discussion. Donald and I have observed that much of the tool preferences come down to whether you live in your browser or your MUA. I think even deeper than that is which tools (and the workflows you've personally built up around those tools) helps *you* better manage your engagement in a topic. Tools can help, for sure, but it's really about controlling the information that you care about, or even more importantly ignoring everything you don't care about. For me, I'm more effective in my MUA so I prefer email based tools. Cheers, -Barry