Mailman 3 August 2016 - Overload-sig

Fwd: [Python-ideas] From mailing list to GitHub issues
by Guido van Rossum 17 Aug '16

17 Aug '16

Heh, I'm not the only one with this idea... --Guido (mobile) ---------- Forwarded message ---------- From: "Arek Bulski" <arek.bulski(a)gmail.com> Date: Aug 13, 2016 07:32 Subject: [Python-ideas] From mailing list to GitHub issues To: <python-ideas(a)python.org> Cc: I have been a subscriber only for few weeks now but I dont like the mailing list at all. First, I get all the topics even tho Windows encoding is not of my interest. Second, most of the text is auto quotes anyway. Third, editing posts can sometimes be helpful, for correcting typos and such. 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. Unfortunately it seems that moving away from existing ways always meets with a lot of inertia. On the other hand, python is probably one of most actively developed langs around so maybe it is doable. I put my proposal on the forum floor to discuss. Cheers to all active participants. _______________________________________________ Python-ideas mailing list Python-ideas(a)python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

7 8

Agenda and Current Status
by Stephen J. Turnbull 17 Aug '16

17 Aug '16

I'm sorry it has taken so long to produce this. It's still not as complete as I would like, but the thread on Python-Ideas makes "doing something now" important. I definitely have a Mailman bias, but I think I've tagged all cases where that affected presentation of this report. Please let me know if you think I've been unfair in any way. Since this is primarily aimed at current SIG members, but will likely be referenced by new ones, I append a brief description of the SIG "charter" and the available channels at the end. Agenda with Item Status ----------------------- 1. Define "overload" by identifying specific issues that make Python channels "tiring" to use, and evaluate the importance of addressing them. So far we have: (a) Proliferation and durability of off-topic threads. (b) A variant of (a) specific to Python-Dev is repeated posting of theoretical objections to patches whose basic rationale was thrashed out in the tracker or on -committers, but those objections have already been satisfactorily rebutted. (c) Nonlinearity of discussion on mailing lists due to concurrent posts which are largely redundant, yet start their own subthreads. (d) Burnout by experts who would like a "you have to be this tall" rule to participate in discussions in their fields. (e) Moderators can't identify bad actors without reading everything or depending on member reports. (f) The pool of moderators is too small. We haven't explicitly evaluated any of the above as valid issues we "must" address. But all have come up frequently or from Important Contributors (including but not limited to the BDFL). I'm probably missing some. Additions or comments on validity welcome. 2. Identify various communication platforms that may improve on the current use of mailing lists as the primary channels for discussions that should be auditable in the future. So far we have: (a) Mailman 2 (mature traditional mailing list). (b) Mailman 3 (immature next-generation mailing list). (c) Discourse (mature(?) best-of-breed web forum) (d) GitHub tracker (mature(?) best-of-breed issue tracker). By "maturity" I means that as far as I know the upstream project believes the platform to be feature-rich, and may not be excited by the idea of supporting our use case. 3. Test the platforms. So far we have: (a) Mailman 2. Obsolete; I believe there is consensus that Mailman 3 is *already* a big improvement over Mailman 2. (b) Mailman 3. Currently the most active channel for Overload-SIG. I believe there is no consensus: Mailing list advocates are happy with it, but at the present it doesn't help enough for those with (good) consumer-grade MUAs, and it can't solve the nonlinearity problem to the extent that discussants use mail. (c) Discourse. Currently inactive. Consensus seems to be that it has many nice features, but overall the level of enthusiasm was not so high. (Sorry for the vagueness, please comment!) (d) GitHub tracker. Unimplemented. 4. Identify features that help address issues defined in 1. (a) Notifications of new threads. (b) Priorization of "interesting" threads by personal criteria. (c) Manual thread muting. (d) Synchronous posting (you can't post unless all posts to date have been "seen" by your client). (e) Thread editing (moving posts to a more appropriate thread, for example). (f) "Voting" to identify bad actors, thus empowering moderators. (g) "Voting" to identify good actors, to automatically identify and/or promote potential moderators from the population of frequent posters. Again, I'm sure I missed a lot. 5. Generate a "feature" matrix from item 4 to provide as much "objective" comparison as we can get. Not started. 6. Discuss "posting topicality" criteria to complement vague judgments of topicality. Chairman's prerogative. AFAIK nobody else really wants to talk about this -- but I consider it essential for real progress. Also note that for the "voting" features (4f, 4g) to work well, we'll need to establish conventions for interpreting "votes", and therefore, rules for when and how members "vote". What We Have Learned So Far --------------------------- Specifics are described as "item status" above. This section is my general, and quite personal, impressions of the tenor of discussion so far. I'm sure nobody is surprised, but it was a good idea to set up best-of-breed implementations of each platform. It has the advantage of allowing "head to head" comparison of modes in one (but only one) realistic setting, that of discussion in this group. I personally was surprised that so many issues came up even without really experiencing any of the issues that lead to formation of this SIG. It also encourages thinking about things like "Mailman with Feature X that Discourse has" (nb, preferring Mailman is my bias, YMMV). I think this is likely because I perceive no consensus of enthusiasm for any of the platforms so far tested (and my bet is that GitHub will be similar: there will be nice features, but no consensus that it dominates the alternatives). I predict this is going to mean that the responsiveness of the projects providing various communivation platforms to our needs, or our willingness (and ability) to develop an appropriate fork, is important. Compare experience with Roundup. About Overload-SIG ------------------ This SIG was established to deal with the problems that occur in mailing lists as the number of participants and posting rates increase. Examples include nonlinearity of threads such as when several posters post highly redundant responses concurrently, and a greater tendency for off-topic threads to persist. These issues have become pressing on python-dev and python-ideas at least. The SIG has several experimental channels using different discussion modes, and is prepared to instantiate more. Currently available: https://discuss.python.org/c/overload-sig This is a Discourse forum, hosted by python.org. Register as usual for Discourse. Currently inactive, mostly we've moved to Mailman 3 *for now*. https://mail.python.org/pipermail/overload-sig/ This is an archived Mailman 2 list, obsoleted by the Mailman 3 list below. Discussion has moved to Mailman 3 permanently. https://mail.python.org/mm3/mailman3/lists/overload-sig@python.org/ This is a Mailman 3 list. We currently use Mozilla Persona for registration and authentication. You can use a couple of social auth systems for authentication, or register your email with Persona in the usual "get a token URI in the mail" fashion. (The Login button leads to a registration link.)

6 13

Base64?
by Donald Stufft 13 Aug '16

13 Aug '16

Mailman2 archives to 2016/07: https://mail.python.org/pipermail/overload-sig/." <overload-sig.python.org> List-Help: <mailto:overload-sig-request@python.org?subject=help> List-Post: <mailto:overload-sig@python.org> List-Subscribe: <mailto:overload-sig-join@python.org> List-Unsubscribe: <mailto:overload-sig-leave@python.org> I replied to one of Brett’s post, he says he got the reply correct and that it shows up on HK correctly, but when mailman sent the reply to me, I got a massive spew of base64: https://s.caremad.io/FrXHi4gxH6/ What in the world did I break? — Donald Stufft

3 6

best way to keep up on only threads I choose to care about?
by Brett Cannon 09 Aug '16

09 Aug '16

From within HK, how do I find out what threads have new posts (the front page seems to list the 5 latest, but what happens when there are more than that)? And is there a way to mute threads so I don't get notified of any more comments? Right now it seems that all there is are favourites, so that would mean needing to discover that a thread is new, read it, and if I have any passing interest in keeping up to mark it as a favourite and then watching there. But then that would lead to a ton of favourites which won't be usable if they don't sort by latest activity. And tags search the individual emails and don't show a thread overview so I can (ab)use them for that. Basically how am I supposed to manage the email volume from HK?

3 3

what happens when people get downvotes?
by Brett Cannon 09 Aug '16

09 Aug '16

Question that popped into my head that lets me also test out HK is what happens if someone gets a bunch of downvotes? For instance, if someone is consistently getting their emails downvoted and they hit some ratio of good to bad, will they be automatically muted/blocked/kicked off the list? Or is there a way for an admin to know someone has hit a rather negative ratio? And is there some way HK tries to prevent vote spam? Basically I'm wondering if there's an easy way to deal with bad actors beyond manual reporting that someone is viewed as such and admins needing to make a call without some objective data to back up their decision.

2 2

Archive question
by Skip Montanaro 03 Aug '16

03 Aug '16

Hopefully since we are supposed to be kicking the tires of the MM3 version of the list, it's appropriate to ask somewhat meta questions about it. Is the archive supposed to consume so much screen space to display so little information? I didn't see any settings link in the archive section, so may have missed the opportunity. Still it seems like when viewing the first page of the archives you should see more than four threads. I realize not many threads have been created so far (this will probably show up as thread #5), but the amount of wasted vertical space seems large to my unadjusted-to-MM3 eyes. Skip

5 8

where does everything sit?
by Brett Cannon 02 Aug '16

02 Aug '16

I asked two weeks ago on discuss.python.org but only Donald replied with a guess of where things sit. Are we currently waiting for a test instance of MM3 to play with? If so where does that currently sit and is there anything we can help with to make it happen? If that's not what's holding us up then what is?

6 14

Gmane may be shutting down
by Brett Cannon 01 Aug '16

01 Aug '16

Looks like the maintainer is burning out: https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/ If gmane is shut down it will impact the accessibility of our MM2 lists I suspect as gmane seems to be popular enough, so our work may have just become a bit more important.

7 10

Testing the MM3 overload-sig
by Guido van Rossum 01 Aug '16

01 Aug '16

I've just subscribed to the MM3 overload-sig. The archives are empty, presumably because they haven't been migrated from MM2 yet. I'm curious whether this message will appear in the MM3 or the MM2 version of the list -- or both? --Guido

2 2