Understanding PEP discussions

It seems like one goal of Kirigami is to handle those three difficulties, by grouping and summarizing discussions. So your feedback about how it’s doing would help improve its output.


I’m not sure how realistic the nuanced slow mode you propose is. If there’s a well supported plugin that enables that, we can look into it, but it sounds like it would require a lot of work to customize for each topic. Current slow mode applies to everyone, and that usually works well enough.


While Kirigami is an interesting approach to summarizing a messy discussion, remember that this forum is a moderated space and you can contact the mods.

The author(s) or any user can flag a discussion at any time if they feel it is being derailed. Moderators can leave instructions, place it in slow mode, close it until authors can respond, notify disruptive users, and more. Unfortunately, most people forget they can ask the mods for help, but it’s much easier for mods to act if they see flags. It is not against the CoC to flag posts or ask for help keeping a topic on track. At worst, we’ll say that we’ll keep an eye on things and wait for more context.

All that said, we (mods) vastly prefer when things are running smoothly and we don’t need to get involved. That’s why we lay out participation guidelines for everyone to follow. The more people that demonstrate healthy participation, the better everyone will do at it. For example, a PEP author can steer their discussion with a message such as “I’ve heard this feedback, please discuss other parts.” (Or ask mods to do so if they feel uncomfortable.)

Remember, ultimately the steering council will review the proposal and discussions, and make a decision. They’re aware of the difficulties with online communication, and can observe who is dominating a conversation and who said what they needed to and then let the conversation move on.

1 Like

Even if I really agree with you - I personally find myself really hating to do that and to “preserve the thread” you would need to be so reactive that it would almost feel that thread authors are shutting down conversations they don’t like.

I think the best example of the “what is wrong with DPO” can be found in the PEP 810: Explicit lazy imports . This thread is very much a picture perfect capture of the problem.

I’m “really not concerned by throttling down conversation”, if we (myself first) were all taking 30min to think, think again and adjust before posting the community would actually speed-up not slow down.

I think we are trying … There’s no cost to experiment besides a few of us throwing some hours away. @savannahostrowski has graciously offered to help with FastAPI Cloud hosting.

I would like to find a way so that we can experiment, I’m opened to spend some time building “discourse extensions/plugins” if that’s what it takes and iterate/experiment, and if it doesn’t work: totally fine ! However, I personally hate complaining about something and doing nothing to fix the problem.

I just pushed an update with a new topic radar feature

I’m actually fairly surprised that it did surface accurately exactly what we are talking about on the thread.

@willingc I think you will like that !

1 Like

It’s true that is one goal. To me, the largest goal is to provide signals about a discussion:

  • who is posting
  • how the conversation flows over time and over topics
  • selecting posts by a keyword
  • adding a visual mapping of a conversation
  • adding a dataframe interface where people can filter and sort based on their preferences

Ultimately, I’m looking for more customized views of a conversation to increase my understanding of its topics, areas of common ground, and areas that need further discussion.

I’m going through the some of the research: Researchers - kirigami and Research signals - kirigami

I view the kirigami app as one way to ease the burden of long threads and reading a wall of text.

Another mechanism could be more finely scoping discussions within a thread to one topic vs. the entire PEP. When consensus is reached on a specific topic, a wiki post could be created from a summary of the thread.

Another alternative would be to create a HackMD doc seeded with a specific question. People could respond to the topic with a limited word count. The document’s purpose would not be to debate positions, but instead to capture viewpoints first.

Personally, I believe that the long running discussions are a bottleneck to forward progress.

2 Likes

I don’t want to derail this discussion, but I do want to flag this point.

Authors of PEPs are supposed to control and manage the discussion, and have not only the right, but the responsibility to shut down unproductive digressions.

I’m very much in favour of tools that help PEP authors do this, but I don’t think we should be worrying too much about helping general readers deal with discussions that have got out of control - “the PEP author isn’t keeping discussion on track” is, to me at least, an important signal in itself. If a discussion becomes unmanageable, the author can always close and restart it.

2 Likes

This feels over-engineered to me, but one very helpful thing would be for the topic creator to be flagged somehow (the same way that core devs are flagged, for instance). Knowing immediately if the person speaking is the one who “owns” the discussion is, IMO, very useful.

4 Likes

How would you see that work ? Genuinely interested

The longest thread takes just 213 minutes to read. It has only 473 posts. The reading time varies only with reading speed. It can be completed in an hour or less if you are able to grasp[1] the intent of each post. I am not even a native speaker, and I have had no issues so far.

I have read 54k posts so far, and I have found many gems[2] in them. Any kind of limit would have hindered these gems from being buried in these threads.

The human mind surpasses so-called AI or any man-made algorithm in pattern recognition, intuition, and similar abilities, and you could easily profile each participant based on their past participation.

I had no issues reading the entire thread twice; it is quite enlightening, and the PEP authors did an excellent job managing it.

This raises the question: why is this thread such a picture-perfect illustration of the problem, and what problem or problems does it highlight?


I tried Kirigami, and it is quite useful for identifying convergence and divergence, as shown there.

One point I am not sure about is whether this thread is about changing participation rules, or about researching discourse in general, and Python discourse in particular, as a separate project.


  1. If you are experienced in the topic being discussed, you have no trouble following the conversation. ↩︎

  2. If you truly know a subject well, you can keep going forever because there’s always more to explore. ↩︎

1 Like

All I meant was that I see tools like Kirigami as being more targetted at topic authors, rather than at discussion participants.

Before asking the SC, maybe spin up a demo Discourse instance to experiment with the options, so we can see how it works and there’s something more concrete to ask? And find some other servers with extensions/plugins already enabled.

2 Likes

The linear nature makes it very difficult to get a good sense about the evolution of one specific topic (or otherwise to ignore a specific topic to focus on smthg else). I do believe that threads would be of great help to that extent

Forgive me if I find a mild bit of irony in this, but those of us participating through “mailing list mode” with threading mail readers do in fact get proper threaded/branching discussion trees within a topic, since Discourse’s E-mail messages preserve parent message ID references via In-Reply-To headers.

It never dawned on me that Discourse’s web interface view doesn’t thread discussion topics similarly, since I don’t generally look at it.

2 Likes

So if email is properly threaded, does that not imply that the data is there and all that is needed is an alternative web frontend that presents the discussions in threaded form? Presumably a 3rd party site like Kirigami could be created that gave a threaded UI to Discourse, for people that prefer that view?

If that is possible, I’m surprised it doesn’t exist somewhere already - so what am I missing?

2 Likes

The data is in the UI too, if a user clicks reply on a message (instead of the bottom of the topic) or quotes a message, then there is a link back to that message from theirs. The UI could use a lot of work though, it’s easy to miss in many cases, and obscures that it’s actually a chain/tree of replies.

For example, I clicked the reply button on your message for this message. But since it’s the next message after yours, and I didn’t use a partial quote, it’s not shown in the UI. It’s probably visible in the API Carol is using too, which could help with analysis.

1 Like

Maybe I gave it a difficult thread to chew, but IMO the results for the sentinel thread are incomprehensible: Kirigami E.g. the top topic there (MISSING Checked Isinstance Missingtype) is something where I have no clear idea what it is trying to say.

(also, minor annoyance: Forward and back buttons don’t switch between the different tabs, this implementation as a single-page app is currently a hindrance to it’s usability)

1 Like

Folks, Feel free to leave issues on the repo GitHub - pykirigami/kirigami: Shape and cut text · GitHub

The feedback is helpful. The app is a very, very early days prototype.

4 Likes

Alright … My ruby is a bit (probably a lot) rusted … It’s been a LONG LONG time …
But it’s done I managed to create a plugin that implements threads.

The data was already there indeed :wink: Some tweaks can be done but it was a fairly “lightweight” modification.

And for those who don’t like … You can flatten the tree

I can’t remember if it was someone at PyCon or here who suggested that - but topic author can actively organize the discussion by moving a post from one thread to another.

Which would greatly help to do that:

CC: @willingc @barry @savannahostrowski

3 Likes

I’d like that, but also with a PEP discussion, the topic author is often under a lot of pressure, so hopefully high trust level community members can also do that (same as editing other people’s post titles).

3 Likes

Well the good thing about “me writing the plugin” is that we can literally make it do whatever we want (as long as it’s technically possible and reasonable implementation wise).

Though my perspective aligns with @pf_moore, that should be the PEP author’s role. If they can’t “organize their discussion” i don’t see how we can help any further to be honest

I’m gonna try to deploy it somewhere that way we can “play” with it. I forgot how painful ruby web services were and my laptop is suffering :sweat_smile:

2 Likes

Thank you, David for pointing this out. Now that the crush of beta 1 PEP decisions and PyCon are over, I expect the SC will come back to the issue of our DPO discussions. My own personal feeling is that PEPs in and of themselves are relatively fine, but the discussions about PEPs needs improvement.

If you have feedback and constructive thoughts that you want to share with the SC and can’t or don’t want to share them here, there are multiple ways to get in touch, including the steering-council tracker, office hours, and the steering-council mailing list.

2 Likes

I agree with @barry’s general framing about the discussions being more challenging than the process. I agree with @Rosuav that the PEP author shoulders much of the emotional burden of reorienting the discussion (such as “do I steer the conversation away” or “ask for a calming in rapid fire replies”) when there are strong opinions expressed in a thread. I feel that the PEP delegate also shares that burden.

For folks who know Discourse better than I do, is it possible to every 20 posts or so recap key discussion points into a wiki post?