Change: Changes Discussion Only On Devel List #3677
Labels
No labels
document it
fast track
meeting
next release
nonresponsive maintainer
packager revocation
pending announcement
provenpackager
python 2 exception
self contained change
stalled
Status
Accepted
Status
Duplicate
Status
Insufficient data
Status
Invalid
Status
Rejected
system wide change
updates policy exception
vote-in-progress
No milestone
No project
No assignees
11 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
fesco/tickets#3677
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Starting with Changes targeted to Fedora Linux 46, discussion of Fedora Changes as part of the Changes Process will happen solely on the devel mailing list and will no longer be simultaneously discussed on Fedora Discussion (the Discourse forum). Changes will continue to be announced on Discourse in read-only topics to provide a bridge between the two platforms. This Change aims to improve communication by avoiding having two separate mediums for the same discussion.
Owners, do not implement this work until the FESCo vote has explicitly ended.
When a FESCo member has marked this ticket as APPROVED, you may proceed with the implementation. See the FESCo ticket policy and the Changes policy for more information.
If no decision has been rendered after 7 days from the filing of this ticket and no indication (such as a -1 vote) that this will be taken up at a FESCo meeting, please feel free to ping for a status update.
REMINDER: This ticket is for FESCo members to vote on the proposal. Further discussion should happen in the Discourse discussion linked above. Additional discussion may happen on the Fedora Devel mailing list.
+1 (as Change owner)
+1 (as Change owner)
+1 (as Change owner)
Note that there is a contending proposal that is being prepared by @siosm - it's not a 1:1 mapping, and I'm disclosing in advance that while I think wiki as the source of truth is terrible, I'd rather the source of truth be a git repo that allows us to do CI checks on submitted PRs, than using Discourse for it . Forges support Markdown just fine so copying that to Discourse, if we must, would work better than the current state.
I agree with @salimma. As I've said, I would really like to re-explore our usage of the wiki for Change submission, but as a separate discussion. If this Change doesn't pass, I suppose we could consider shutting down the devel list (I'm not convinced that's a good idea, but yes, it's the natural counter proposal), instead, but I really don't want to make Discourse the source of truth or have to copy things from Discourse to Antora.
-1, while I understand the proposers ideas and want to unify communication I do not feel it is worth to make a part of the community unheard (and upset), whichever part that is. Some other interesting things came out of this (like the usage of the wiki versus other change proposal processes).
For the record, I also don't think Discourse should hold the final source of truth (accepted changes). Copying them to Antora (Fedora Docs) would just be a script that looks for approved changes, pulls the markdown from the json, runs them through pandoc (or some lighter converter), and checks them into git. If lacking that automation is a showstopper, I'll write it.
+1 (as Change owner)
Also, please keep this focused on the proposal at hand. It is very narrowly scoped - process changes like moving away from the wiki are explicitly not in scope here.
EDIT: I apologize, I missed the previous comment before posting my long one 🙈. I concur: we should keep this ticket focused on what's in scope of the current proposal.
Original:
I wanted to say it makes more sense create a different thread to discuss ideas surrounding Change submission, (since this Change was deliberately scoped to the discussion part only to avoid muddling the discussion), but now it's hard to separate the two, since I guess using Discourse for submission implies using it for discussion also :).
I don't think it's just having to convert between markup formats that's bad (even if we have a script to do it1). It's loosing the edit history with detailed change data that git or Wiki software provides. (Discourse has limited edit history, but it'd be lost when converting and copying the proposal to a git repo.) The template form demo (https://discussion.fedoraproject.org/t/f46-change-proposal-changes-discussion-only-on-devel-list/197431/104) requires you to fill out the entire Change at once which does not work well when collaborating with others or writing out a larger change in multiple sittings. (Also, there is some weird scrolling bug in the template form on Firefox.)
If we want to do gitops instead of the Wiki setup, I think we should do it the normal way without Discourse as an intermediary. And I think a proposal to do gitops should come with concrete plans for automation that offset the additional burden that gitops can cause for change submitters2. Other than split brain discussion, one of the main pain points brought up in the pre-Change devel discussion was that there are too many places and too many formats, and the 'Discourse+copy approved Change to git' idea makes that worse, since we'd have two sources of truth for different process stages with different markup languages at the same time. And there's still the issues with centralizing discussion on Discourse that were mentioned previously.
and we would also need to rewrite all the PgM scripts that rely on the Wiki as a source of truth; it's not just text conversion. ↩︎
There was some disagreement about whether wiki WYSIWYG editing and dealing with wikitext or using a more familiar markup format in git is easier or harder to work with. I'll note that Changes are mostly technical and even less technical Changes require basic git knowledge since Fedora Docs, Design, Websites, Spin and Edition image configs, etc. are all already in git. ↩︎
@decathorpe wrote in #3677 (comment):
I appreciate wanting to keep the scope of the vote narrow, but this isn't really a fair framing. Moving away from Discourse closes out a number of possible process improvements which are right there with existing or minimal new tooling. (Including addressing @gotmax23's concerns in the post above.)
-1 here. I'm sorry this causes stress and work for others, but I think it's worthwhile for allowing more participation.
-1 as I wrote in the thread.
If folks disagree with my alternative proposal, I would prefer to explore git only / forge based options instead of going back to email only.
I'm going to put my FPL hat on real tight for this comment.
I have concerns on relying on mailinglist for discussion as they are implemented right now because of the lack of moderation tooling. It is my understanding that it is possible to subscribe to the devel list without a fas account and there are no mechanisms like trust levels or rate-limiting post-slowdown mechanisms for the devel mailinglists currently. I just confirmed that I'm able to request a subscription to devel list from one of my alt email accounts and it was accepted. There's no evidence that mailinglists are gated or gatable in any way to encourage better higher bandwidth discussion. At best email moderators can ban someone, and then turn off new subscriptions for a period of time, but that's a pretty big hammer.
This is a non-theoretical concern. I'm not going to name specific email addresses, but we have a situation currently where a person appears to have moved on from discourse where they are being actively moderated to the devel mailinglist where they are not. I've been poked by several individuals via direct messaging in my capacity of FPL to help address the disruption in -devel-list. Because its the -devel-list I have a limited set of tools at my disposal to help compared to discourse the response options I have to coordinate a response to the disruption ae not great. The fact that individual contributors escalated to the FPL via private discussion is an indication that -devel-list already has a problem.
If I had a vote, I would vote against this.
I am sympathetic with the frustration of the fractured communication environment. But if we are going to fix the fracturing problem, then I feel we need to choose the discussion tooling that provides the better choice of moderation tools. Choosing to use mailinglist will likely result in the decay of the high bandwidth discussion in -devel-list as the disruptive voices gather there and drown out useful discussion.
Here is my opinion concerning the technology platforms from a moderation tooling pov:
Discourse likely works best for public discussion because of the available moderation tools in the platform. If you want to have discussion where Fedora contributors are voiced but where disruptive or driveby comments can be moderated this is likely the best option. We have room to explore the use of trust levels there a bit to help curtail driveby disruptions by new or lurking fas account holders.
Forge tickets likely work well for decision-making when its reasonable for discussion to be restrictable to a group. It appears to be possible to moderate if needed by limiting which forge team members can write comments via write access roles while keeping everyone else read-only for in-ticket discussion if decision-makers want to have a disruptionless space to talk among themselves within public view.
Public mailinglists don't appear to have strong fas group membership requirements at present (-devel-list does not at present) and still allow for driveby email subscription. As such mailinglists are the most susceptible communication channel of the 3 to discussion disruption and signal-to-noise problems. It's not even clear to me that people who sign up for the mailinglist via email subscription have been asked to agree to the CoC.. which is another sort of problem.. if disruption on -devel-list rises to a CoC violation, did we do the necessary due diligence to set behavioral expectations for mailinglist subscribers who aren't FAS account holders?
So, we keep getting told that FESCo needs to moderate discussions under its umbrella better, so in that spirit: Please don't post discussion contributions in this ticket tracker, it is for administrative use only. Discussion is supposed to happen in the corresponding thread on discussion.fp.o.
addendum: Reading this again myself now, this was unnecessarily sharp, and I want to apologize for that. It was only supposed to have been a reminder of
--- (see above), which is from the standard template for Change tickets.
This was discussed in today's meeting (meeting log).
+1
(I reread the discussion and there's a lot of good points on both sides. Ultimately, for me, the deciding factor is that having a discussion in multiple places is significantly worse than having it one place. So I think we should pick one. And as for which one to pick, for the technical discussions which happen in response to the Change Proposals, the mailing list is more suitable. By nature of those discussions, we care more about packagers and long-term contributors than about reaching every Fedora user and contributor. In that narrow scope, the tradeoff between mailing lists and the forum favors the lists quite strongly. I think it's fine to have those discussions on the mailing list, while some other discussions primarily in other places.
Also, this decision is for now. If the mail-quoting in discourse gets better, or the threading starts working, or the problems with moderation on the mailing lists turn out to be too hard, the decision can be revisited. But even if the choices that we have right now are not perfect, I think it's better to make a decision and improve things incrementally.)
Hi folks, with this change passed (as per FESCo meeting yesterday), can I consider this change effective immediately? I have a bunch of changes I need to announce so wanted to check what process to use.
Yes. Consider it effective immediately.
It seems I forgot to do the bureaucracy on this one.
This was discussed during the meeting yesterday.
AGREED: APPROVED (+5, 0, -3)
Did the summary get sent yet?
Yeah, yesterday: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OWVDSPNC3AFCO6KZQ5GJOZWA6AFTMFXV/
Ack 🫡
We first need someone with Discourse access to change the poll creation automation, as discussed in the proposal. to create polls where the results and voters are always visible.
ugh, I think I have the power, but none of the know-how :(
Perhaps myself or @gwmngilfen could assist?
Would someone have a minute to check:
https://discussion.fedoraproject.org/t/this-is-a-test/201092/2
Please, and thank you.
(xref discussion/tickets#11)
The wording looks good to me. It looks like we also need to set
public=truein the poll markup (i.e., "Show who voted" in the poll creation UI) to properly show the results. Compare to https://discussion.fedoraproject.org/t/this-is-a-test/201092/4.ok new way of it is live:
https://discussion.fedoraproject.org/t/f46-change-proposal-crystal-language-system-wide/201104/2
Im also continuing to link the 'discussion post poll' in the change wiki page.
Lt me know if Ive missed anything/anything needs changing. Thank you!
Thanks Aoife! I think the only thing left is "closing" the new Discourse threads so they are read-only.,