Requests for Comment/Central notice changes

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Proposals 1 and 2, added by the proponent, fail, with fairly strong consensus against Proposal 1. There is also some degree of consensus against Proposal 2. Regarding Proposal 2, specifically, and not its sub-proposal regarding a Global Sysop campaign type, this is something where RfC is procedurally not an appropriate venue. A request to add banner campaign types, make central notices translateable, or similar administrative request should be requested at stewards' noticeboard, as some users noted below. Regarding the Global Sysop campaign type sub-proposal, it fails because of the parent proposal failing. As well, as a global role that provides no advanced level of access requiring an NDA, is primarily a crosswiki counter-vandalism role, is a delegated role that assists Stewards for limited purposes, and which cannot operate on any wiki marked private due to not having read rights globally, this would lead to an over-population of central notices, thus leading to people ignoring them, or worse, and, in turn, leading to apathy to all central notices in general, which would be contrary to their stated purpose. Proposal 3, while a good-faith proposal, was a late-stage addition not added by the proponent but which is unrelated to this RfC. While it might be prudent to have a later community discussion regarding the administration of Miraheze social media accounts, which have, historically been, and, at present, are managed by the SRE team, any such discussion would likely need the board's input, given that the social media accounts manage the official company communications and which are not exclusively used for community purposes. Dmehus (talk) 11:19, 30 November 2021 (UTC)

---

These are a couple of proposals related to central notices, previously from Requests for Comment/Improvements for notification of global discussions where they happened to have failed due to insufficient consensus. Hopefully a more clear consensus can be found in this discussion.

@K599: If you do not mind I have a suggestion for you. I would suggest that before opening RfCs you create a draft in your userspace and ask for opinions and advice at Community Noticeboard. I do not mean to cause any offence but your proposals so far have been vague and do not seem to have attracted much support. It would in my opinion be beneficial if more users participated in the drafting of such proposals. I am willing to help and propose some of my ideas for the reform of CentralNotices, for example a certain threshold for when a CentralNotice should be created for permissions requests, etc. --DeeM28 (talk) 13:13, 23 November 2021 (UTC)

Proposal 1: Central notice duration

Central notices for discussions should last while the discussion is open for people to participate. As in, the central notice would only be removed after the discussion is resolved.

Support

1.  Support Having notices last while the discussion is still open helps to lower the possibility of people missing the discussion even when it’s still open for participation. K599 (talk) 18:50, 19 November 2021 (UTC)
2.  Weak support Anpang Talk Stuff 00:43, 23 November 2021 (UTC)

Oppose

1.  Oppose Vague proposal, doesn't define anything. Agent Isai ^{Talk to me!} 16:04, 22 November 2021 (UTC)

   This is only "vague" if you don't understand what a discussion is, which is a concept that I would think most people would be familiar with. Anyway, I've made an explanation for what a discussion is in the comments section, which this oppose comment fails to acknowledge. K599 (talk) 20:45, 22 November 2021 (UTC)

2.  Oppose I don't know why to strengthen centralnotice. What is this change for? Already been turned down once and will you try again? This CNotice is of no interest, and for me, even annoying as I use anonymous and I have to keep closing it every time I open it again. CNotice will become more irritating with these changes. Of course it's important on SOME occasions like: Fundraising (which should last at least a few days). Already, Cnotice about requests for votes, it should only be in Meta. In other wikis this is of no interest. It seems that the community likes to live in that corner where the flies are also. YellowFrogger (✉ Talk ✐ Edits) 01:02, 23 November 2021 (UTC)

   First of all, the proposals that came from the other RfC were ones that had insufficient consensus, there wasn't a consensus against them, so there really isn't anything wrong with trying to find a more clear consensus on these proposals. Second, the campaign types proposal below would give you the option to turn off all central notices if you want to avoid seeing them, specifically by being able to use the "Banners" section of your user preferences, which without that proposal would leave that section as doing nothing. Wiki communities would also be able to use this opt-out feature on whole wikis, which would include any anonymous users, if my suggestion in the comments section is taken. Finally, I find your claim that every wiki community hosted on this wikifarm has "no interest" in requests to be doubtful, because one person does not have the ability to read the minds of thousands of individuals from all across the world. The requests that are posted on central notices are ones that have global consequences, as in they can potentially affect any or all wikis and/or users. That's not something that only Miraheze Meta should be concerned with, it's something that should have the attention of generally any wiki community hosted on this wikifarm. Really, this proposal exists with the goal of making sure that most people don't get left out of participating in discussions just because the central notice disappeared even when the discussion is still open for participation. After all, the purpose of discussions is to get feedback from wiki communities and they would need some way of knowing that a discussion exists for them to provide their insight, and so it would make sense to only remove a central notice notifying of a discussion once the discussion closes, as it would be that point when the discussion doesn't need to gather people anymore, not while it's still going on. K599 (talk) 02:01, 23 November 2021 (UTC)

3.  Strong oppose The idea behind this may be somewhat understandable but the arguments against it are very strong in my view. Firstly, what happens in the case that there are multiple proposals being opened during the same two weeks. Are users to see 2-3 different CentralNotices? Second, what happens if a RfC is open for multiple months as was the case with the Community Directors RfC? Thirdly, I repeat my view that I do not find it appropriate to increase the frequency of CentralNotices in such a way that would dilute their function as something "special" that needs to be consulted; there should not be a CentralNotice running every day of the year. Therefore I strongly disagree with this especially because it would mean that if an RfC is not closed in (for example) two months there would have to be a CentralNotice. Additionally to these arguments while there may be some users that infrequently visit Miraheze and would consequently not have seen the CentralNotice on Day 1 and 2 it is unlikely that users who do not frequently visit Miraheze would be very interested in participating anyway so for who would the week or month long CentralNotice be? I agree that improvements to the current system are necessary but mandatory time limits are not a necessary improvement in my personal view and I believe that sitenotices for discussions should not last more than a few days. Alternative methods to inform users should be sought out preferably. --DeeM28 (talk) 13:13, 23 November 2021 (UTC)

   @DeeM28: When the recent Request for Stewardship was open, a central notice was put up for that while the fundraising central notice was also running, and how that worked was one or the other would be shown by random chance. I don't claim that this is necessarily desirable, though it does answer your question about multiple central notices at the same time. For requests that are open for long periods of time, my view is that if the closer for those requests is letting them stay open for so long, that would be because they believe that the discussion needs that time to find a clear outcome, and discussions are meant to gather people to give their input, so if a discussion is being kept open longer, then the methods being used to notify of the discussion's existence should stay up to let people know that there's still something to discuss there. This proposal doesn't increase the "frequency" of central notices, it would be increasing the duration of individual central notices. The same standards for what central notices are made would still be the same even with this proposal. For that matter, the second proposal doesn't really change the standards either, as they're based on what kinds of central notices have generally been done before, as seen on Special:CentralNotice (the only exception would be Community Directors, but there hasn't been any requests for that yet, and since other discussions related to Community Directors have had a central notice, I believe the inclusion of Community Directors to be reasonable). It's really just the third proposal that possibly alters what gets a central notice, but it doesn't say that every one of such a request would get one, it just says to allow the possibility of such. I think that your claim that infrequent users of this wikifarm would supposedly lack interest in these discussions is too far of an assumption to make, because an infrequent user is still a user of this wikifarm regardless, they would still be using something that's hosted by this service even if it happens to be infrequent use, and they should still be informed about something that they use if they desire it so. Another comment I'd like to say is that the people who handle central notices still retain judgement over what to make a central notice for, and they're not being forced to make a central notice for every possible thing imaginable, this proposal is making it so that the duration of central notices has a relation to the duration of the discussions that they would be notifying of. K599 (talk) 16:38, 23 November 2021 (UTC)

4.  Oppose I agree with the comments above and think that the way it's currently worded implies that all CNs must be open for all RfCs from the day they're opened to the day they're closed. I see above in a comment that the proposer says that people who create CNs still retain discretion. In that case I'm not sure what this proposal wants to achieve if it's supposedly not a requirement to keep CNs up for the duration of an RfC (which I disagree with). Reception123 (talk) (C) 06:17, 29 November 2021 (UTC)

Comments

 Question: This proposal is rather vague, what is the definition of 'discussion' in this context? Agent Isai ^{Talk to me!} 20:28, 19 November 2021 (UTC)

I would think that the definition of a discussion would be obvious, but I guess since it's been asked, a discussion is a sort of gathering of people, open to any user in this case, where they discuss a sort of change, generally to the workings of a system, or to elect an individual to a position.

Or we could just say, from the campaign types being proposed below, Requests for Comment, Requests for Stewardship, Requests for Global Sysop, and Requests for Community Director. You could also just say any sort of proposal in general to summarize the above. K599 (talk) 22:15, 19 November 2021 (UTC)

You know what, here's an alternative wording if anyone happens to not like the current wording:

Central notices with the purpose of soliciting participation from wiki communities for an event or a discussion should last while that event or discussion is open for people to participate. As in, the central notice would only be removed after the event or discussion has closed.

If you think this would be a better description, then go vote for this one. K599 (talk) 21:03, 22 November 2021 (UTC)

 Comment: I don't have too much of an opinion here, and I think part of the problem is that not many other users do either. Unless it's something with dramatic potential, the chance of substantive input is not great even if it was advertised in the method presented through this post. While principally I agree (partially) with below and somewhat disagree on the last proposal, I think the second and last ones are clerical details that SRE could technically draft, present on the CN and then execute with whatever inputs are received.This point in particular has a stronger reach as it will probably be on by default and so there will likely be more wikis that seek to turn off their notices as a result of anything leveled as discussion being thrown into their wiki notices. I think discussions should meet some minimum obligations to be posted, as I'm not in favor of doing them when people want to RfC for just anything; be it someone misunderstanding the process, invalid RfC that is doomed anyway, an RfC with hardly any traffic from Meta itself, or one which gets snowballed. In cases where there is 'more to them' I'd like to see them advertised. But there would be certain discretion required to do it in the way I suggest. Bottom line I don't have much of a stake in this method.

The only path of meta promotion I'd really care to pursue (which should also be considered mainly just by SRE for now until it's feasible, and proposed when we can actually see it through) is notices through echo, so that wiki management (sysop/bc) will get the pings for these things happening as long as they're opted in, but they're not necessarily splashed across communities that may have little inherent reason to care or frankly, stake in the process. Just opt in and opt out tools are not enough to me, but the ability to fine tune in this way. I'd also prefer to strongly encourage participation, but for opting in, not by giving them the full deal and inclining parties to opt out piecemeal or in full. Those who are interested should participate, those who are not I don't think need to be sucked in for inputs they don't have passion for. --Raidarr (talk) 09:26, 23 November 2021 (UTC)

Proposal 2: 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
• Requests for Stewardship
• 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.

Support

1.  Support Campaign types would be a good way for individual users to have better control over what kinds of central notices they would see. K599 (talk) 18:50, 19 November 2021 (UTC)
2.  Support the idea but  Oppose the procedure. As it is mentioned by Agent below I have to agree that I do not feel that it is very appropriate for an RfC to be getting in such details and mandating certain campaign types to be used. I would prefer that this takes place in CN where a more flexible discussion can take place. I do agree however with the idea and think it is important to create different campaign types and allow users to opt-out (or even opt-in) depending on what interests them. --DeeM28 (talk) 13:13, 23 November 2021 (UTC)

   I feel that it's your preconceived notions that a RfC supposedly can't be a place for "flexible discussion". If you want certain details to be changed or added, then simply say so, you could even add on additional proposals or amendments to help. K599 (talk) 16:38, 23 November 2021 (UTC)

Oppose

1.  Oppose Out of scope for an RfC in my opinion. This feels like something for the Community noticeboard. Agent Isai ^{Talk to me!} 16:05, 22 November 2021 (UTC)

   The Requests for Comment page says "Requests for Comments are designed to be an easy way to gather community feedback on certain proposals, ideas and issues and to form a community consensus." This is a proposal, and it is seeking to get feedback to form a consensus, being that it is proposing a list of campaign types and discussing whether these kinds of campaign types would be appropriate to use. K599 (talk) 20:51, 22 November 2021 (UTC)

   @Agent Isai: This would also fit a Phabricator YellowFrogger (✉ Talk ✐ Edits) 01:07, 23 November 2021 (UTC)

   YellowFrogger, getting consensus from the communities is important to ensure that any changes are made without going against what people actually want. It's something stated on Miraheze's landing page that they're "community-centric" and they "work together" with wiki communities, and a Request for Comment fulfills such a function, while a phabricator task is just for technical purposes. K599 (talk) 02:11, 23 November 2021 (UTC)

2.  Weak oppose Anpang Talk Stuff 00:46, 23 November 2021 (UTC)
3.  Oppose Many many things for other wikis. I already mentioned why above. YellowFrogger (✉ Talk ✐ Edits) 01:04, 23 November 2021 (UTC)

Comments

• On another note, this can presumably work with ManageWiki to apply for a whole wiki. To sysadmins, this would presumably be done by using a custom variable to set $wgDefaultUserOptions['centralnotice-display-campaign-type-whatever'] = 0. K599 (talk) 18:50, 19 November 2021 (UTC)
•  Comment: I feel like this is out of scope in part for an RfC. If anything, the suggestion should be moved to Phabricator or first discussed on #miraheze-sre on IRC/Discord for a technical discussion. Agent Isai ^{Talk to me!} 20:31, 19 November 2021 (UTC)

  My thinking is that the list of campaign types to be used should have the consensus of the communities. K599 (talk) 22:18, 19 November 2021 (UTC)

Include RfGS as a campaign type

Include Requests for Global Sysop in the list of campaign types.

Support

1. This is a global role that is granted major abilities, such as globally locking users. I think that should at least be considered. K599 (talk) 18:50, 19 November 2021 (UTC)

Oppose

1.  Weak oppose Partially in part per my above point that this might be better suited for discussion first on #miraheze-sre but even if that weren't the case, I feel like both Global Sysops and Steward requests should be included in one category as both have powerful effects globally. Agent Isai ^{Talk to me!} 20:39, 19 November 2021 (UTC)

   Well, whether those requests should be partitioned or not would be one particular thing that I think can be discussed in this RfC. K599 (talk) 22:21, 19 November 2021 (UTC)

2.  Weak oppose Anpang Talk Stuff 00:48, 23 November 2021 (UTC)
3.  Oppose YellowFrogger (✉ Talk ✐ Edits) 01:08, 23 November 2021 (UTC)
4.  Oppose As per my opposition to the strict mandating of types in Proposal 2. --DeeM28 (talk) 13:13, 23 November 2021 (UTC)

Proposal 3: 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.  Support 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) 15:38, 29 November 2021 (UTC)

Comment

•  Rational for reintroduction: This proposal (as amendment 3.1) gained community consensus in the previous RfC but was (correctly) failed on the grounds that proposal 3 (for notifications on social media) had not passed. I do however think that it makes sense on its own and that some of the people who supported amendment 3.1 would like it to be passed even though proposal 3 failed especially given that proposal 9 passed. As such I am proposing it as a separate item. ~ El Komodos Drago (talk to me) 15:37, 29 November 2021 (UTC)
• The wording in this proposal is a bit vague. It's not clear who appoints this role even though the first support !vote mentions the community appointing the role. Additionally, this role handles private information to a certain extent as users DM Miraheze accounts with private information sometimes so I'd like to see this role be an NDA-required role. On top of that, it also might be a little redundant as SRE has a "Community Engagement Specialist" role which manages social media too. Agent Isai ^{Talk to me!} 16:17, 29 November 2021 (UTC)

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section