Proposal to move Change discussion from devel-list: technical implementation discussion

Project Discussion
,
1

As you may have seen, I recently proposed that we move discussion of Fedora Changes from the development mailing list to this forum. After a week or so, that thread has run its course, and so I filed a FESCo ticket for approval.

I won’t duplicate the whole proposal or FESCo ticket, but for now, the specific proposal is simple:

  • Changes will be announced on devel-announce as they are currently
  • But discussion will be directed to the corresponding topic under a #change-proposal tag

Anyone who is not interested in the rest of Fedora Discussion but who would like to follow change proposals can mute everything else and “watch” only this tag. As discussed in the thread, this allows for receiving the discussion by email and participation by reply.

I am not currently proposing further active migration of topics from devel list. This is an experiment which we can learn from and adjust – or back off from, if need be.

“Important stuff getting discussed in tickets most people don’t notice” is one of my main motivations for this proposal in the first place, so I don’t want to be hypocritical and discuss possible implementation details there. So, instead: this topic!

2 Likes
2

In the ticket, @churchyard asks:

Do I assume correctly that the discussion topic will be created by whoever announces the change on devel-announce and a link to it will be included in the announcement email?

If people naturally hit Reply on the announcement email and that reply goes to the devel list, do you plan to try directing the people to the forum or not? I am afraid this could create a discussion that is scattered across two disconnected places.

Which is a good point.

Keeping the tradition of announcing changes on devel-announce is meant to mitigate one of the biggest concerns raised: email comes to you; you don’t have to seek it out. While you can subscribe to get emailed when something is posted here (see Guide to interacting with this site by email), it’s a different interface and people would have to actively subscribe.

Plus, broadcast announcements are well-suited to mailing lists.

But, I don’t want to make the fragmentation problem worse. Possible approaches are:

Idea 1: If discussion starts on devel, gently point people here instead.
Pros: Easy, up front
Cons: Constant work, annoying for everyone, can’t be enforced

Idea 2: Preemptively lock threads so they can’t be replied to
Pros: None really. But a possibility.
Cons: Not even sure how to lock threads in mailman, just know we’ve done it before on rare occasions. Not obvious: locked threads can still be replied to, just won’t get posted, so that’s not great.

Idea 3: Decouple devel-announce from devel, set reply-to to bounce
Pros: Relatively easy, mostly solves problem
Cons: People who are only subscribed to devel[1] will have to change behavior or miss out. Also, breaks easy devel list discussion for other announcements.

Idea 4: Decouple devel-announce from devel, somehow link replies into thread
Pros: Reply to devel-announce remains easy
Cons: Requires writing and running some bridge app. Replies are “write only” from the devel-announce side.

Idea 5: Don’t send anything to devel-announce after all
Pros: Easy!
Cons: Devalues devel-announce instantly. Requires people to change behavior to subscribe here.

Idea 6: Only send abstract to devel-announce
Pros: Easy. Doesn’t require devel-announce or devel-list changes, and still reaches existing subscribers
Cons: Not as useful as getting the whole thing

After thinking about it, my suggestion is the last one — send only an abstract to devel-announce. The devel-announce messages could prominently point to the Discussion thread, and also include instructions on subscribing to #change-proposal, either for all posts and replies or just first posts (the latter would be like subscribing just to (a subset of) devel-announce).

I don’t love this, but it’s kind of a price we pay for trying this one step at a time rather than everything all at once. (If we removed devel and kept just devel-announce, we wouldn’t have this problem.)

Anyone have a better idea?

  1. even though we do recommend subscribing to them both ↩︎

3

From my perspective not sending anything to devel-announce at all is not an option.

Yet can we make it so that you don’t need to send to devel-announce@ additionally to posting to the discussion forum? Can we “subscribe” devel-announce@ to watch the first post of topics in a certain tag/category?

If I understand correctly the main issue is how to prevent people from replying to the announcement by adding devel@ into CC.

The change of Reply-to can’t really help here, can it?

In general, no matter how we announce a change, there is no way to not let someone simply forward it to devel@ list and starting the conversation there. So it seems that it should be driven by an agreement, rather than a technical implementation.

4

I don’t think there’s a capability to generate anonymous emails — that is, not linked to a particular account. We could investigate developing / adding that functionality. Or we could make some kind of script which “cleans” incoming messages and sends them out. Or, my preference[1] a little bot that gets a webhook on posts and then generates the email.

Well, the status quo is that devel-announce messages are also CCd to devel list. (I’m not sure offhand if this is automatic or by convention.)

I think that’s “idea 1”. But people won’t always remember that agreement, or, you know, will decline to agree. Then what?

  1. same as my suggestion for building a tool to bridge from here to public-inbox ↩︎

5

I think the goal here should be to prevent threads on fedora-devel “by accident”. I.e. somebody gets the notification mail and presses reply-to-all out of ingrained custom. If somebody intentionally adds fedora-devel@ to the address list, this is outside of scope. We can’t prevent people from doing that, and also I think we wouldn’t want to, because as long as fedora-devel exists, there might be cases where a thread there is desired (i.e. for the foreseeable future).

I’d vote for this option. We’d need to loudly announce that this is happening, so that people either check that they are subscribed to fedora-devel, or subscribe to a relevant tag on discussion.fp.o. (We need a tag on discussion.fp.o to which people can subscribe for announcements anyway.)

I find sending-abstracts-only extremely annoying. Fedora Community Blog does this (e.g. “Friday’s Fedora Facts: 2023-17”, but not picking specifically on FCB, I guess it’s a wordpress thing), and I read half of the text and then I’m thrown out of the context by having to click on a link to read the rest of the text. For the common case where the text in the email requires no response and no action, just reading the text in the browser would be enough, no context switch to another medium necessary. Sites like linkedin also do this, to drive the user to the website. I think we should avoid doing something similar also to avoid the bad association.

Instead, always send the full text in the email notification, but add prefix and suffix notes where replies should be made.

2 Likes
6

Convention.

1 Like
7

Yes, this is what I had in mind as well. We can setup some helper methods (reply-to, disclaimer in the text) and point in the right direction, but we can not go much further than that.

I generally agree with your point. But I see a possible reason to send the abstract and not the full change description to a mailing list: dealing with edits.

Discourse allows editing of the top post. It provides detailed changelog for the edits too. And I was thinking that during the change discussion it might be useful to address comments directly by editing the top post, so that it has the corrected up to date version.

If we use this approach, it makes the information we send via mailing list outdated.

By sending only the abstract we say: refer to the source of truth, not this mail.

This of course is valid only if we agree that top posts in Change discussions are editable. I am not quite sure myself if we want that.

8

I think updating the top post (the change proposal) is a nice advantage to this approach — at least for small changes. Significant updates might be done by closing the original topic and opening a new one, to keep the conversation coherent.

I don’t think that’s only possible with the excerpt-announcement — after all, the devel list status quo is that the devel-announce/devel post doesn’t change.

The block pointing to the discussion thread and giving disclaimers could include explanation.

9

Oh, also: a problem with the current process is that the wiki page sometimes gets changed significantly with no one noticing — sometimes after the FESCo vote, without bringing it back for review. (I haven’t seen this ever happen with bad intent, but it still isn’t great.)

This doesn’t inherently solve that, but if we (for example) automatically synced changes from the wiki, they’d be more visible to more people.

10

For larger edits I would expect the person who does the edit also add an explicit comment to the thread on what kind of edit was applied.

I agree that wiki has a similar problem.

Btw, should we also discuss possible removal of the wiki page from the process, or is it out of scope for now?

11

I tried to sneak it in there but Ben gave me a disappointment dad look, so I backed off. One windmill at a time!

12

No, just… no. Changing the top post makes some, most, or all of the
discussion after the top post irrelevant or useless, and only serves to
confuse folks that were not following from the very beginning.

(Especially since the actual proposal’s authoratative text already lives
elsewhere)

Unless there’s a clear deliniation in the thread when the top post (or
any previous post in that thread) changed, and from/to what. Perhaps a
saner approach would be to post updates in the thread, and only edit the
top post to link to the “new/current” text later in the thead?

One question – Does discourse send out a new notification/whatever when
posts you’ve seen (top post or others) are edited?

  • Solomon
13

It does not. See https://meta.discourse.org/t/not-receiving-notifications-for-edited-wiki-posts-unless-you-are-the-author/24340

14

I think the goal here should be to prevent threads on fedora-devel “by accident”. I.e. somebody gets the notification mail and presses reply-to-all out of ingrained custom. If somebody intentionally adds fedora-devel@ to the address list, this is outside of scope. We can’t prevent people from doing that, and also I think we wouldn’t want to, because as long as fedora-devel exists, there might be cases where a thread there is desired (i.e. for the foreseeable future).

I’d vote for this option. We’d need to loudly announce that this is happening, so that people either check that they are subscribed to fedora-devel, or subscribe to a relevant tag on discussion.fp.o. (We need a tag on discussion.fp.o to which people can subscribe for announcements anyway.)

yeah, I am for that option as well.

I find sending-abstracts-only extremely annoying. Fedora Community Blog does this (e.g. “Friday’s Fedora Facts: 2023-17”, but not picking specifically on FCB, I guess it’s a wordpress thing), and I read half of the text and then I’m thrown out of the context by having to click on a link to read the rest of the text. For the common case where the text in the email requires no response and no action, just reading the text in the browser would be enough, no context switch to another medium necessary. Sites like linkedin also do this, to drive the user to the website. I think we should avoid doing something similar also to avoid the bad association.

Instead, always send the full text in the email notification, but add prefix and suffix notes where replies should be made.

I think at least to start with we should do that too… it’s more in
line with what people are expecting. If any changes are made, they
should be made to the wiki page (Until/unless we change the source of
truth to something else). Although I don’t mind the discussion post
being updated too…

kevin

1 Like
15

Yeah, there definitely should only be one source of truth.

16

There’s an option for categories and tags to watch first post. Couldn’t we set up a service account that watches the first post on #change-proposal and has devel-announce@fp.o set as the notification e-mail? That way replies would be posted in the Discourse thread since that post has the originating e-mail address of the discussion.

I’m not sure how to achieve this if the idea above can be implemented. Maybe the devel-announce list settings can be modified to implement that. Otherwise a template for change proposal announcements on Discourse could be set up. I think the wiki uses a template as well.

The same applies to the wiki. For that we send the entire announcement and any edits that happen after the announcement go unnoticed if one only follows the discussion on the devel list.

So, this problem is not new and people should be aware of it. But i wouldn’t hurt sending a reminder and/or including it in the supplementary footer.

I agree. But that source could either be the wiki or Discourse. Both provide an audit trail (history of edits).

This could be solved by asking / instructing people who submit a proposal to leave a comment on a suggestion / improvement comment that it has now been integrated. Or, alternatively, if discussion was spread out, leave an explicit Edit: in the original post.

I’d love to see a picture of that… :wink:

17

I thought of this too but forgot to list it. The problem is that these messages have metadata tying replies to the account it’s sent for, so we’d need to strip that out — it can’t be used for someone else to reply.

18

I had to let this digest. Couldn’t quite make sense of it why you’d do
such a thing. User identification should happen some other way. But I
guess that’s due to e-mail being so easily forged.

Stripping out that identifying meta data may break e-mail replies
entirely. We would need to test or ask upstream how to make it work, if
at all.

I was also wondering how things are setup now. All announcements are
sent to devel list by @bcotton. There’s probably a reason for that. I
guess the reason is some kind of automated/scripted approach with some
checks. That approach may also work for the discussion/list announcement.

19

The reason is because policy requires it.

I wish. Everything is manual for reasons that I won’t get into here.

1 Like
20

Thinking about implementation details, particularly with @decathorpe’s suggestion of having @fesco members moderate the discussions…

Tags are generally lightweight, with permissions and workflow automation tied to categories. For that reason, we try to use categories lightly — but this may be a case when we do want one. A Changes subcategory of Project Discussion could be configured so FESCo members are moderators, and the Change Wrangler allowed to create topics and use a set of appropriate tags.[1]

Alternatively, I can grant FESCo members moderation for Project Discussion and keep it to just the tag.

The good news is that it’s pretty easy to go back and forth as we figure out what works best — topic URLs won’t change.

  1. including release-number tags like f39 ↩︎

1 Like