Requests for Comment/Improvements for notification of global discussions

This Request for Comment is intended to make it so that notification of any global discussions is spread more effectively. After all, as Miraheze's landing page says to be "community-centric", it would be great to have many wiki communities that use Miraheze participate in these discussions, if they choose to. For clarity, global discussions are defined here as discussions that potentially affect any or all of wikis and/or users of Miraheze. Recent Requests for Comment have gotten a central notice and/or an announcement in the Discord server, but I believe that other global discussions, as listed below, should also get a chance, along with some adjustments detailed in the proposals below. K599 (talk) 20:46, 16 August 2021 (UTC)

Global discussions include:
 * Global Requests for Comment
 * Global proposals on community noticeboard
 * Requests for Stewardship (including nomination and revocation)
 * Requests for Global Sysop (including nomination and revocation)
 * Requests for Community Director (including nomination and revocation)

The proposals should apply for all future and ongoing global discussions. In addition, note that the intent of these proposals is to become policy. __NEWSECTIONLINK__

Proposal 1: Central notices
A central notice should be made for each global discussion, lasting for as long as the discussion is open for people to participate.

Support

 * 1) Central notices are a straightforward way of notifying everyone. Having them last for as long as the discussion is open helps to lower the possibility of people missing the discussion even when it’s still open for participation. K599 (talk) 20:48, 16 August 2021 (UTC)
 * 2)  Oh yes, absolutely. To be fair though, it makes it difficult for other users (new and old) to navigate through the requests for whatever permission, as long as they have met the criteria for such requirement. I'm definitely casting a strong support vote on this one. DarkMatterMan4500 (talk) (contribs) 22:39, 18 August 2021 (UTC)
 * 3) Central notices would increase the likelihood of user engagement throughout Miraheze's communities in global discussions. &#32;  Miraheze Logo.svg centrist16 | P mail.svg | Discord color D.svg  &#32; 21:20, 19 August 2021 (UTC)
 * 4) I don't always check into Miraheze Meta, but I regularly look at many other wikis on Miraheze. Though, if users don't want to see CentralNotice banners, then they should be able to opt-out just like it is for Wikimedia wikis. &#8211;  MJL &thinsp;‐Talk‐☖ 22:11, 19 August 2021 (UTC)
 * 5)  — it may be annoying to many users (including me) but it can be useful to increase the participation in discussions. And there should be an option to opt-out of receiving those central notices. ~ Mazzaz (talk)  07:35, 22 August 2021 (UTC)
 * The issue with that would perhaps be that some users would like to see some notices like for important Requests for Comment but they wouldn't necessarily be interesting in seeing every single user that is a candidate for Steward or GS. Reception123 (talk) ( C ) 18:32, 27 August 2021 (UTC)

Oppose

 * 1) A CentralNotice for all types of requests would be nice but may annoy users and in turn cause them to turn them off completely and then cause them to miss important global notices.  Agent Isai  Talk to me! 20:56, 16 August 2021 (UTC)
 * 2) Rather than add complexity through these means I would rather encourage better Meta organization to route people to discussions and a culture of encouraging interested users and admins to take a look. Or the lighter (if more complicated to execute) concept of using the notifications system. I do not believe going through CentralNotice and additional controls for opt in/out is the way. --Raidarr (talk) 12:39, 25 August 2021 (UTC)
 * @Raidarr I'd say that "better Meta organization" is unlikely to help for discussions in particular, because one of the reasons for this RfC is that most editors don't check Miraheze Meta, and are generally just focused on the wikis that they regularly edit. This is why some sort of global notification would be needed to notify people, as otherwise it would just be Meta users that would easily find global discussions.
 * As for notifications (from Echo, I assume), I do think this would be a good tool, but it seems that such a feature isn't currently implemented, considering this Wikimedia phabricator task that's had seemingly no progress for about 8 years. I'm not aware of any methods of on-wiki global notification other than central notices, and since Miraheze has already been using central notices, I'd say that it shouldn't be that problematic. K599 (talk) 21:17, 25 August 2021 (UTC)
 * 1)  I'll have to oppose this for what some may consider rather minor but which I find important. I take issue with the fact that it is proposed that all requests for Stewardship and Global Sysop will require a Central Notice. Sure, on the face of it it might seem fair that everyone should get the same amount of advertising but on the other hand this would be prone to 'abuse' (not in the malicious sense). It would be possible for people who clearly have no chance of becoming GS or Steward to request it and therefore to have their own Central Notice on all wikis and waste users time who would come to Meta just to oppose per NOTNOW/SNOW or simply because it's someone that's not experienced. This would likely cause an excessive amount of Central Notices which could become annoying for users and perhaps even have some users ignore what Central Notices say if they are too pervasive and often; we clearly don't want to have Central Notices running at all times. I'm not yet sure what a better alternative would be but I can't support requiring a Central Notice for every single candidate to global positions and I think an alternative would be interesting. Reception123 (talk) ( C ) 18:28, 27 August 2021 (UTC)
 * 2)  I agree with what has been said above. I especially think that it would be a problem if we had to have a Central Notice for every single RfC which would include ones that are less consequential for Miraheze in its entirety. I also think that it would not be a good idea if every person who applied for global positions such as Steward and Global Sysop got a Central Notice because it would allow a lot of inexperienced people to get a CN for a position that it is unlikely that they will obtain. If I put myself in the shoes of a regular user I do not think that I would like to see Central Notices constantly on my wiki in particular if it is for candidates that have no chance of passing and will be immediately rejected. I acknowledge that it would also not be just to have notices for some users and not others: that is also a problem because of who would have to make that determination. I am not currently sure what a solution to this problem would be but I do not think frequent Central Notices is a solution to this problem and as it was said above it would likely annoy people and maybe even be a reason for them to disable Central Notices thereby prohibiting them from knowing when important discussions are taking place. A potential solution to this problem would be to have a limited time for Stewards and Global Sysops to apply (for example every 3 months) but this would have to be proposed separately of course. I would probably also recommend an email list or an Echo notification list that interested parties can subscribe to and where they would indeed be notified of all global discussions if they so wish. --DeeM28 (talk) 15:05, 29 August 2021 (UTC)
 * After reading a discussion below I would be interested in an amendment that includes certain requirements that would be met before a CN is created (for example X number of support votes). DeeM28 (talk) 15:19, 29 August 2021 (UTC)
 * 1)  per above. In principle, this sounds like a good idea, but it's both too vague and broad at the same time for functional implementation. In practice, this would effectively neuter central notices to the point that everyone would tune them out, which would be completely counter to the good-faith aims of this proposal. As such, I have to oppose this. Dmehus (talk) 19:20, 29 August 2021 (UTC)
 * 2) I agree with the comment made by Dmehus above. In my opinion, central notices should really only be used for the most important of discussions that require widespread community input and consensus. The aforementioned point also opens the discussion, what falls within the realm of "important". In my opinion, discussions on community director appointments should be central noticed as they have a much impactful role on Miraheze outside the digital realm. Requests for stewardship and requests for global sysop I do not believe warrant notices. A less intrusive solution for disseminating such information may be more appropriate. Forgive my ignorance, but I don't know of the whole global proposal concept on the Comm. Noticeboard so I don't believe they need notices. As Dmehus said, the proposal is vague. I believe some Requests for Comment warrant global input as they often have global significance, but how you define which ones deserve such attention is difficult and could lead to controversy. Personally, send all the notices you want, just trying to give a balanced view on this. &#32;  Miraheze Logo.svg CnocBride | Talk | Contribs  22:15, 29 August 2021 (UTC)
 * @CnocBride Global proposals on community noticeboard refers to proposals like the one for "ManageWiki UX Change" and the one for "ManageWiki review changes". That said, it could be argued that such proposals should perhaps be Requests for Comment instead, but currently it seems that such global discussions are being put on community noticeboard.
 * The RfC defines global discussions, at the top of the page, as "discussions that potentially affect any or all of wikis and/or users of Miraheze", which is meant to define which discussions should get global attention. K599 (talk) 16:27, 30 August 2021 (UTC)
 * 1) Craziness! Imagine users of a wiki in another language receiving notifications from other wikis in English. And miraheze does not place ads on its wikis without the permission of the wiki authors. Yellowass.png (talk) 15:05, 6 October 2021 (UTC)

Comments

 * Just copying from Discord: In the README for the CentralNotice extension, there's a config called $wgCentralNoticeCampaignTypes, which should allow for users to opt out of specific campaign types in their preferences. That way, users can choose to not see, for example, RfS if they aren't interested. K599 (talk) 21:28, 16 August 2021 (UTC)
 * This could be a good idea for more granular sitenotices, certainly better than the "one size fits all" approach we currently do. Allowing communities to opt into specific categories such as say, elections or RfCs (we'd have to define these), would be an improvement over all or nothing. -- Void  Whispers 22:09, 16 August 2021 (UTC)
 * If Fandom had notified people about major changes like domain name and UI then I probably would never have moved to Miraheze so I think that if there was a major one like a domain name change then this would be a good option. ~ El Komodos Drago (talk to me) 21:43, 16 August 2021 (UTC)
 * would it be possible to do this with an alert/notification instead? ~ El Komodos Drago (talk to me) 21:43, 16 August 2021 (UTC)
 * I very, very much prefer exploring this, if it is viable for our current workforce of course. I would rather not try to bend global notices into doing the job. --Raidarr (talk) 13:15, 19 August 2021 (UTC)
 * If this is successful, will it take effect immediately? DarkMatterMan4500 (talk) (contribs) 22:46, 18 August 2021 (UTC)
 * Not a Steward but yes I wouldn't see any reason why an RfC would not take effect immediately after it's closed unless that is explicitly mentioned in one of the proposals. Reception123 (talk) ( C ) 18:33, 27 August 2021 (UTC)
 * I'd like to recommend that central notices also include some text that instructs people how to opt out of campaign types, to make it clear how to do so. To be specific, assuming that campaign types are configured as mentioned above, users would go to the "Banners" section of their user preferences to choose what campaign types they would like to opt out of. K599 (talk) 22:04, 24 August 2021 (UTC)
 * This, plus the 'notability' requirement (a certain amount of participants/content importance before certain notices go live) would be the most agreeable version of the proposal to me. If certain things could be opted in or out from the start (ie, on createwiki to have an opt-in for these kinds of things) I'd also find this more useful, especially if combined with clear, but non-aggressive notification that anyone including wiki admins can/is encouraged to participate here. --Raidarr (talk) 15:17, 29 August 2021 (UTC)

Proposal 2: Translation of central notices
All central notices should be made translatable. For each central notice, there should be a link to the page where they can be translated, saying "Translate this notice!".

An example of such a central notice is this fundraising notice from early 2020.

Support

 * 1) Translations are important for allowing non-English speakers to understand what's going on. K599 (talk) 20:48, 16 August 2021 (UTC)
 * 2) Translations would be awesome for global notices.  Agent Isai  Talk to me! 20:56, 16 August 2021 (UTC)
 * 3) as a multilingual wiki farm, providing notices in multiple languages should be very important to us. ~ El Komodos Drago (talk to me) 16:38, 19 August 2021 (UTC)
 * 4) Multilingual accessibility lies at the core of this community. &#32;  Miraheze Logo.svg centrist16 | P mail.svg | Discord color D.svg  &#32; 21:20, 19 August 2021 (UTC)
 * 5) &#8211;  MJL &thinsp;‐Talk‐☖ 22:11, 19 August 2021 (UTC)
 * 6)  ~ Mazzaz (talk)  07:19, 22 August 2021 (UTC)
 * 7)  I do not think there is much scope for opposition to this proposal. I think making Central Notices translatable is an simple task for people who create CNs and if people want to translate notices they should be able to do so. --DeeM28 (talk) 15:08, 29 August 2021 (UTC
 * 8) &#32;  Miraheze Logo.svg CnocBride | Talk | Contribs  22:15, 29 August 2021 (UTC)

Oppose

 * 1)  Not going to lie, but shouldn't this have been filled automatically a long time ago? DarkMatterMan4500 (talk) (contribs) 22:41, 18 August 2021 (UTC)
 * 2) Yellowass.png (talk) 03:43, 7 October 2021 (UTC)

Comments

 * This is more of a process change than a community change. I personally have been trying to make sure all central notices get translated, but there isn't really a good system in place to do so yet. For specific implementation, I think we need a translation group of common messages (such as the translate this notice like that would go in every notice), as well as a common setup for all future notices that is easy to implement with the new notice. -- Void  Whispers 22:15, 16 August 2021 (UTC)
 * I agree, I don't feel like there needs to be a requirement for this, it should rather be a process and we need to figure out how to best implement it. Reception123 (talk) ( C ) 18:37, 27 August 2021 (UTC)
 * I agree with the comments here, so this is where I land. I would just also add that, in practice, translation of central notices is only good as the volunteer translators we have. Central notices are always translatable, and if there's errors in the code preventing that, a note can be made at stewards' noticeboard and a Steward will fix it as soon as they are able. Dmehus (talk) 19:26, 29 August 2021 (UTC)
 * I'd like to point out that it should at least be obvious that several recent central notices don't give a link to translate like the one mentioned above does. Specifically, the one for the recent survey doesn't, the one for community directors reform doesn't, and the one for CoCC abolishment doesn't. K599 (talk) 04:37, 30 August 2021 (UTC)
 * I wondered why no one was translating the latter two banners. In any case, as I say above, these are the sort of things a quick note to Stewards, ideally by way of Stewards' noticeboard, should be able to correct. Dmehus (talk) 04:46, 30 August 2021 (UTC)

Proposal 3: Social media
A post on each of Miraheze's social media accounts should be made for each global discussion. To be clear, Miraheze has a Twitter account and a Facebook account.

Support

 * 1) Good for notifying people using social media. K599 (talk) 20:48, 16 August 2021 (UTC)
 * 2) This is pretty trivial to get done. &#8211;  MJL &thinsp;‐Talk‐☖ 22:11, 19 August 2021 (UTC)

Oppose

 * 1) This would be overtly tedious to do and host.  Agent Isai  Talk to me! 20:56, 16 August 2021 (UTC)
 * What do you mean by "host"? I also don't see how this would be "tedious". K599 (talk) 21:00, 16 August 2021 (UTC)
 * If SRE needs to post an important notice, like this one, then by needing community input, the tweet would be delayed. Or what about a simple tweet like this one? Requiring a discussion would be a waste of time and a tedious task for those setting up the vote. Additionally, I'm sure there'd be very low turn out for this. Agent Isai  Talk to me! 21:03, 16 August 2021 (UTC)
 * This proposal does not mean to make it so that a discussion is needed to make a tweet, it means that when a global discussion is started, a tweet is made to let people know. The tweets you listed are not related to this proposal, and it is not being suggested that any community discussion is needed for those kinds of tweets to be made, or any tweets really. K599 (talk) 21:10, 16 August 2021 (UTC)
 * Ah, I see. Thanks for clearing that up! I think it would be useful only if the discussion reaches only a certain threshold (e.g. an RfS reaches 5 supports) to prevent every single request from cluttering up Miraheze's social media feed. For example, if a new user requests Stewardship, it obviously would fail per WP:SNOW so to prevent every single request from receiving a notice posted on social media, I would suggest a minimum threshold for a notice to be pushed out. Agent Isai  Talk to me! 21:15, 16 August 2021 (UTC)
 * This seems sensible. ~ El Komodos Drago (talk to me) 21:44, 16 August 2021 (UTC)
 * Might be worth having such a requirement in place for other forms of notifications as well. -- Void  Whispers 22:16, 16 August 2021 (UTC)
 * I should have read this part before voting in Proposal 1. I think that is a great idea (to require a number of supports) before creating a CN or posting somewhere. I think a new proposal should be created to this effect as an amendment to proposal 1 which I would then be able to support. --DeeM28 (talk) 15:16, 29 August 2021 (UTC)
 * 1)  While I do believe that it would be a good idea to replicate the announcements on Discord and Central Notices to Social Media I am not sure that doing so via the standard @Miraheze accounts is a good idea. I am not sure if we want to mix up technical posts (for example about maintenance) with community posts. I would possibly be willing to support this if the posts were made by separate community accounts but I am not sure how good that idea is. --DeeM28 (talk) 15:15, 29 August 2021 (UTC)
 * 2)  per my comments above in response to Proposal 1, but also because Miraheze's social media is mainly targeted towards new and prospective Miraheze users; not established users interested in minutiae and administrative matters for discussion. Note that for the purposes of this oppose, I define social media more narrowly as Facebook, Twitter, Instagram, and similar platforms, not Discord and IRC, which I view as more real-time communication platforms. Dmehus (talk) 19:24, 29 August 2021 (UTC)
 * @Dmehus What says that Miraheze's social media needs to be exclusively "targeted towards new and prospective Miraheze users"? I don't see any reason why "established users" shouldn't expect to use Miraheze's social media for finding out about any global discussions. K599 (talk) 04:29, 30 August 2021 (UTC)
 * True, but I mean, historically, Miraheze's social media accounts have largely been used for disseminating information related to Miraheze Limited company updates, new MediaWiki upgrades, new or expanded services, or fundraising initiatives. I would also note that the social media accounts (being Facebook, Twitter, and Instagram) are run exclusively by Site Reliability Engineering rather than Stewards, which would oversee publication of such notices. Not saying that can't be changed, but procedurally speaking, I believe SRE should be first engaged about expanding the scope of the Miraheze Limited social media accounts and to onboarding Stewards as contributors/moderators to those accounts for those more community-oriented purposes. Dmehus (talk) 04:42, 30 August 2021 (UTC)
 * 1) Yellowass.png (talk) 03:43, 7 October 2021 (UTC)

Comments

 * Hmm, this might be tricky to implement, as (in theory), community appointed roles (Stewards and the like) don't have access to the social media accounts. Instead access is limited to technical volunteers. It might be worth discussing opening up additional access, or creating some process by which the community can "stage" messages for social media that a technical volunteer could then post. Thoughts? -- Void  Whispers 22:19, 16 August 2021 (UTC)
 * I think having volunteers who could be able to post notices on social media for this would be good. Agent Isai  Talk to me! 22:43, 16 August 2021 (UTC)
 * Yeah, some sort of "social media manager" role could be a good idea. K599 (talk) 22:55, 16 August 2021 (UTC)
 * how is this phrasing for a new proposal: "A post on each of Miraheze's social media accounts should be made for Requests for Stewardship, Requests for Global Sysop, and Requests for Community Director (all including nomination and revocation) when such requests reach half the number of required support votes (i.e. the support ratio of the minimum number of comments, so 80% of 20 = 16 for Stewards) and Global Requests for Comment and Global proposals on community noticeboard when they reach 3 votes in favour. To be clear, Miraheze has a Twitter account and a Facebook account." ~ El Komodos Drago (talk to me) 16:34, 19 August 2021 (UTC)

Amendment 3.1 Part 1: Social media manager role
A role of "social media manager" is created. Social media managers would have access to Miraheze's social media accounts, currently the Twitter account and the Facebook account, to handle posts that should be made.

This particular amendment does not alter any preexisting access.

Support

 * 1)  This could help relieve some of the load that SRE currently handles.  Agent Isai  Talk to me! 04:12, 7 September 2021 (UTC)
 * 2)  This is out of the scope of normal SRE activity and as a community facing role should be appointed by the community or their representatives. ~ El Komodos Drago (talk to me) 11:16, 6 October 2021 (UTC)

Oppose

 * 1) Yellowass.png (talk) 03:43, 7 October 2021 (UTC)

Proposal 1
The social media manager role is appointed or revoked through community discussion. The requirements for successful appointment/revocation are:
 * At least 10 users make a comment.
 * There is a support ratio of at least 80%.
 * Users are given an adequate time to comment.

Proposal 2
The social media manager role is appointed or revoked through community discussion. The requirements for successful appointment/revocation are:
 * At least 5 users make a comment.
 * There is a support ratio of at least 80%.
 * Users are given an adequate time to comment.

Proposal 3
The social media manager role is appointed or revoked by the approval of stewards and sysadmins.

Comments

 * If you think it should be something different, feel free to make a proposal. K599 (talk) 22:02, 30 August 2021 (UTC)
 * I do believe an inactivity clause should be added (e.g. Role can be revoked if user appointed to role has not had any meaningful interaction with the community and/or no log entries globally in the past 3 months)

Proposal 4: Discord
A message in the #announcements channel of the Discord server should be made for each global discussion.

* Procedural Point of Clarification: This is already effectively the status quo. This is merely the community's endorsement of the status quo, with Stewards determining what discussions merit an announcement, as it is fairly common for malformed global discussions or procedurally invalid discussions to be initiated, for which it would obviously be in no one's interested to be notified of a discussion that was either malformed or procedurally invalid. Proposal 5, which is contingently tied to Proposal 4, even makes that clear. Dmehus (talk) 03:28, 7 September 2021 (UTC)

Support

 * 1) Good for notifying people in the Discord server. K599 (talk) 20:48, 16 August 2021 (UTC)
 * 2)  Agent Isai  Talk to me! 20:56, 16 August 2021 (UTC)
 * 3)  Definitely. Honestly, this should have been done automatically to begin with. DarkMatterMan4500 (talk) (contribs) 22:43, 18 August 2021 (UTC)
 * 4)  due to the frequency of other announcements and because by discords nature all recipients are interested in Miraheze this seems like a no brainer even without any minimum bar for support. ~ El Komodos Drago (talk to me) 13:54, 19 August 2021 (UTC)
 * 5)  A common sense addition that's a quick and convenient way to reach Discord users. &#32;  Miraheze Logo.svg centrist16 | P mail.svg | Discord color D.svg  &#32; 21:20, 19 August 2021 (UTC)
 * 6) Only reason I knew about this RFC was Discord, so... &#8211;  MJL &thinsp;‐Talk‐☖ 22:11, 19 August 2021 (UTC)
 * 7)  ~ Mazzaz (talk)  07:23, 22 August 2021 (UTC)
 * 8) Maybe make it opt-in? &#32;  Miraheze Logo.svg CnocBride | Talk | Contribs  22:15, 29 August 2021 (UTC)
 * @CnocBride I believe that it's already opt-in, as people only get notified of any messages in #announcements if they have the Announcement Pings role, which is attained from following these instructions. K599 (talk) 04:24, 30 August 2021 (UTC)

Oppose

 * 1)  Per my reasoning in my opposition to Proposal 1. I think the same standard should be used for Central Notices when creating announcements in Discord. --DeeM28 (talk) 15:09, 29 August 2021 (UTC)
 * 2)  per the same reason as DeeM28. Note, too, that this proposal is a sub-proposal of Proposal 1; therefore, passage is contingent on Proposal 1 passing. In any case, this already effectively the status quo, with Stewards having discretion to determine what should receive a Discord notice, what should have a central notice, and the like, so as to avoid excess announcement clutter to the point that the announcements' effectiveness becomes moot. Dmehus (talk) 03:19, 7 September 2021 (UTC)
 * I do not see how this is a sub-proposal of proposal 1 or in any other way contingent on proposal 1 passing. These both address different mechanisms of notification. ~ El Komodos Drago (talk to me) 10:47, 6 October 2021 (UTC)
 * 1) Yellowass.png (talk) 03:43, 7 October 2021 (UTC)

Comments

 * 1)  Is this supposed to only affect global discussions (i.e. RfCs and community discussions) or does it also affect RfCs and RfSs? Reception123 (talk) ( C ) 18:30, 27 August 2021 (UTC)
 * The notion of global discussions has been defined by the proposer as meaning all of them yes. --DeeM28 (talk) 15:11, 29 August 2021 (UTC)
 * 1) Note to closing Steward While you might not see it in the same way as I, I believe that it would make little sense to have separate rules for Discord and Central Notices as these things serve the same purpose. So if Proposal 1 does not pass, should proposal 4 pass thereby creating a dual-system where not all RfCs and candidates are advertised via CNs but all are advertised on Discord? --DeeM28 (talk) 15:11, 29 August 2021 (UTC)
 * I believe that's correct, wherein Proposals 2 through 4 would be contingent on Proposal 1 passing, as they are merely administrative proposals that aim to flesh out the nuances not articulated in Proposal 1. Dmehus (talk) 19:29, 29 August 2021 (UTC)
 * @DeeM28 The wording in proposals 2, 3, and 4 does not imply dependency on proposal 1, and doing what is described in proposals 2, 3, and 4 does not physically require doing what is described in proposal 1. Social media and Discord are separate and independent notification methods from central notices, and do not even appear within the same space, as central notices appear on-wiki for those who have not opt-out, while social media and Discord appear on their own platforms. Although proposal 2 is about central notices, it is not limited to the central notices described in proposal 1, being that even if proposal 1 does not pass, Miraheze would still be using central notices as it already has been (though the criteria for using central notices is not currently made explicitly clear in any document), and proposal 2 should still apply to those central notices. K599 (talk) 16:06, 30 August 2021 (UTC)

Proposal 5: To prevent abuse of frivolous discussions
Notifications, specifically the methods described in the above proposals that pass, for global discussions will only be made after a Steward concludes that the discussion is not frivolous.

Oppose

 * Procedural per my comments here. Aside from that and additionally, this is largely the status quo anyway, though not limited merely to be frivolous or not frivolous&mdash;that goes without saying. Discussions which propose to change something on Meta alone would not get a central notice, nor would discussions which either procedurally out of place, in conflict with other policies, or otherwise minor or relatively inconsequential. Dmehus (talk) 03:49, 30 August 2021 (UTC)
 * @Dmehus The RfC defines what it considers to be a global discussion at the top, so this proposal is not for making a central notice for "something on Meta alone". The "status quo" you speak of isn't defined in any policy as far as I'm aware, and besides that, there is a proposal for using social media, which is not part of the "status quo", and the central notices proposal includes "lasting for as long as the discussion is open for people to participate", which is also not part of the "status quo". K599 (talk) 04:17, 30 August 2021 (UTC)
 * 1) Yellowass.png (talk) 03:43, 7 October 2021 (UTC)

Comments

 * If it is unclear, "frivolous" refers to cases of w:WP:NOTNOW or w:WP:SNOW. If you think it needs to be defined more thoroughly, then feel free to make another proposal or amendment. K599 (talk) 03:36, 30 August 2021 (UTC)
 * I know that a common suggestion being made on this RfC is to have a minimum number of supports, and if you want to propose that, you're entirely free to do so, but I don't think the number of votes or comments correlates to whether a proposal is abuse or not, as people can just get their friends or spammers to meet whatever the minimum would be. K599 (talk) 03:36, 30 August 2021 (UTC)
 * Procedurally, proposals should not be added to an RfC well after an RfC is already underway as often times users do not return to the RfC to express a comment on the added proposal. This is why is it is preferred to have a fully crafted RfC, ideally discussed in advance via one's user page before moving forward. As such, I cannot support this on procedural grounds. Dmehus (talk) 03:48, 30 August 2021 (UTC)
 * @Dmehus If you believe that users aren't necessarily going to see newly added proposals, then just mention all of those users. And even in a "fully crafted RfC", I don't see how it would be impossible for amendments to be desired, and making a new RfC for any amendments would end up taking more time and effort. K599 (talk) 04:09, 30 August 2021 (UTC)
 * Not all users check, or are even aware of Echo notifications, as partially evidenced by the number of users that submit duplicate wiki requests when their requested wiki was either (a) approved or (b) declined. Dmehus (talk) 04:36, 30 August 2021 (UTC)

Proposal 6: Make campaign types for central notices
A campaign type can be set for central notice campaigns, allowing users to opt out of specific campaign types in their preferences, specifically in the "Banners" section. Here is a proposal for what campaign types Miraheze should use:
 * Fundraising
 * Surveys
 * Maintenance
 * Requests for Comment
 * Global proposals on community noticeboard
 * Requests for Stewardship
 * Requests for Global Sysop
 * Requests for Community Director

To make it clear how to use preferences to opt-out of campaign types, some text instructing people how to do so should be added to central notices.

In technical terms, campaign types are configured with $wgCentralNoticeCampaignTypes in LocalSettings.php.

Oppose

 * 1) Yellowass.png (talk) 03:43, 7 October 2021 (UTC)

Comments

 * I don't know if it'd be possible to configure CentralNotice in a way that would allow wikis to opt-in/out of campaigns. After reviewing the documentation, it seems like opting-in/out wikis from a campaign is done manually via Special:CentralNotice. I'd like to see if this is technically feasible before supporting so I hope SRE can comment on this. — Preceding unsigned comment added by Agent Isai (talk • contribs) 04:11, 7 September 2021 (UTC)

Proposal 7: Central notice duration
Central notices for global discussions should last as long as the discussion is open for people to participate. As in, the central notice would only be removed after the discussion is resolved.

Note that what is described here is part of proposal 1. This proposal is for this part to be voted on separately from proposal 1. Also, this proposal is not dependent on proposal 1, this proposal would still apply to the kinds of central notices for global discussions that would be made even if the other proposals don't pass.

Proposal 8: Support for Echo notifications
Use Echo notifications to notify about global discussions. Specifically, as it is described in this Wikimedia phabricator task. This proposal is just to show support for the creation of such a tool since, as can be seen in the linked web page, this feature has not been developed yet.