On Wed, 13 Feb 2019 at 19:56, Steve Dower <steve.do...@python.org> wrote: > > On 13Feb2019 1112, Brett Cannon wrote: > > > > > > On Wed, Feb 13, 2019 at 2:55 AM Paul Moore <p.f.mo...@gmail.com > > <mailto:p.f.mo...@gmail.com>> wrote: > > > > On Tue, 12 Feb 2019 at 22:00, Antoine Pitrou <anto...@python.org > > <mailto:anto...@python.org>> wrote: > > > Here is a 161-message Discourse thread (at the time of this writing): > > > https://discuss.python.org/t/pep-517-backend-bootstrapping/789 > > > > As someone directly involved in that discussion, with a strong need to > > understand all of the points being made, that's a great example of > > both the benefits and the flaws of the discourse model. > > > > > > Can I ask if that entire thread is on topic, or is there a reasonable > > point in that discussion where side conversations could have been broken > > off into a separate topic(s)? When email threads tend to reach that > > length there have been side discussions that could have become their own > > topic if someone thought to change the subject and Discourse allows for > > having an admin break posts off at any point and I'm curious if it would > > have been helpful and people simply didn't think about it (I know I > > don't always think of it immediately yet). > > My feeling (as I followed the entire discussion from the start) is that > the side discussions all tied back, rather than diverging permanently. > So at best it would be "you 2-3 go and discuss this part separately and > come back when you agree", which as we know is often followed up by "you > other 2-3 re-discuss everything they already discussed since you weren't > part of the side discussion".
Precisely this. I don't know *how* I would have split off a separate sub-thread in Discourse if needed (it's easy enough in email by changing the subject, I presume it's not much harder in Discourse?) but I don't think there was any obvious point at which that would have helped rather than hindering. And as the goal of the whole thread was to reach a consensus on a change to PEP 517, if we *had* split things up, there would have been the problem of pulling the subthreads together again later. > So in this case, I don't think it would have benefited from being split > out. In fact, I think it worked best in the linear form because when > someone (typically either Paul or Thomas) declared a summary, it > basically forced all the branches to converge. I can't speak for Thomas, but I think I would have done exactly the same in mailing list form. As I said elsewhere, I don't think the difficulties are particularly about linear vs threaded forms. > It's a long discussion because it has no clear answer and the concerns > are on the level of "what weird things will the entire world do if we > offer this", which can't be tested. As far as asynchronous, online-only > options go, I'm not convinced that any other approach would have worked > better. When trying to do those summaries, and trying to catch up now (I've been unable to follow the discussion closely for a week or two) I'd say the Discourse format made it a bit harder. But that's *not* linear vs threaded, it's more about things like how quoting works and how comments are linked back to what they are referring to. (On the other hand, rich text, and not having to deal with email mangling of quoting structure, help a lot). Big discussions like this one are hard *whatever* medium is used. I don't think Discourse is *bad*, I just don't think it's noticeably *better* than email. And my major concern is that I don't think Discourse will scale well to high-traffic categories with substantial numbers of this sort of discussion (and worse, I think the existence of high-traffic categories could have a detrimental effect on more moderately-sized ones). But I think it's too early to tell for sure. Back to the original question, about the committers list: 1. I think the committers traffic is the right sort of size for Discourse, and works OK. 2. I think Discourse is bad for "quick turnaround" things like votes, because it's too easy for people not to see the discussion until it's too late (and no, I don't think formally posted voting periods will help much there). It *may* be possible to alter people's expectations to make the slower turnaround acceptable - it's not like (say) a core developer vote has to be resolved particularly quickly, after all. 3. I don't think any conclusions we draw based on the committers category should be assumed to scale to larger lists (whether in terms of number of messages, number of participants, length or complexity of threads, or anything else). Paul _______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
