Meta:Community portal

From Meta
Jump to navigation Jump to search
OOjs UI icon alignRight.svgMeta Community portal
This noticeboard is for community discussions relating to Meta only. For matters that need a local administrator's attention, please visit Meta:Administrators' noticeboard. For general help, please visit the Community noticeboard. For requests that require Steward or Global Sysop intervention, please visit the Stewards' noticeboard.

On the Meta community portal, you can:

  • Start a local (Meta only) community discussion.
  • Discuss Meta pages and coordinate efforts to reorganize or fix them.
Add a new topic
Archives of the Community portal [e]   

Header colors

As you all know, Template:Header is used as a header on many pages. For the sake of variety and to clearly distinguish pages, what header color do you all think different page types should use? For example, I was thinking perhaps using green (the default) for documentation pages, purple for anything clerical (request pages, noticeboard, etc.), and yellow for talk pages. Any other suggestions? Agent Isai Talk to me! 08:52, 2 February 2022 (UTC)[reply]

I'm not picky on the particular tone, but I do strongly recommend it always remains a subtle color to use. Perhaps something can be done with the header line; reducing the colorful of the background, but making the line a subtle distinction. --Raidarr (talk) 13:05, 2 February 2022 (UTC)[reply]
I think the colors should remain the same regardless anyway. DarkMatterMan4500 (talk) (contribs) 13:17, 2 February 2022 (UTC)[reply]
I was planning to create a Community portal pretty much today. Do you have the power to read thoughts? Anyway, how like this will it be done? --YellowFrogger (talk) () 18:13, 2 February 2022 (UTC)[reply]
Leave it the way it is, @Agent Isai: these colors match up a lot. --YellowFrogger (talk) () 18:17, 2 February 2022 (UTC)[reply]
Yes, that's the plan, to use a combination of light, pastel-ish colors. My reasoning for such a standardization is because all RfX and noticeboard pages already use purple and to prevent all pages from looking bland, I wanted to see if anything could be done so that Meta doesn't look so unstyled. Agent Isai Talk to me! 18:44, 2 February 2022 (UTC)[reply]

Inactive bots

Void-bot (talkcontribslogs) and TranslationHelper (talkcontribslogs) have been inactive on this wiki since 23 December 2020 and 4 February 2021 respectively. Should the rights be removed? --Magogre (talk) 03:35, 6 February 2022 (UTC)[reply]

After reading the bots information page itself: Meta:Bots, I didn't see any part that inactivity of the tools with the bit can cause the revocation. Therefore, we will see the opinion of seconds. --YellowFrogger (talk) () 03:59, 6 February 2022 (UTC)[reply]
I agree. So far as I know, there is no inactivity policy regarding bots. Magogre, you could propose removing the flag via regular means but I don't see a need to do that unless it is being misused. Naleksuh (talk) 04:02, 6 February 2022 (UTC)[reply]
I also agree that there is no policy regarding inactivity of bots (and that is why I posted here). The bots have been inactive with zero edits in the last year (Void-bot has zero edits overall). Why do they need the flag, if they are inactive. --Magogre (talk) 04:13, 6 February 2022 (UTC)[reply]
Regardless of whether or not they need it, usergroups are added and removed in line with policy, that's why they exist! Naleksuh (talk) 04:18, 6 February 2022 (UTC)[reply]
Well, therere is no policy regarding removal of bots which are inactive, so I don't need to be in line with no policy. The consensus here is what I am looking for to proceed with what to do with them (whether to remove or not)! --Magogre (talk) 04:30, 6 February 2022 (UTC)[reply]
The bot is correctly identified as such and while it is not active on Meta, it serves a crucial role on cvtwiki. It is advisable just to let it be imo, and instead focus on other applications such as the noted administrator inactivities as something that could reach the policy threshold or other forms of Meta cleanup with a more visible impact, something which I intend to contribute to myself in due course.. Raidarr (talk) 09:54, 6 February 2022 (UTC)[reply]
Void-bot indeed performs a great task on cvtwiki by logging actions by CVT. But it is completely inactive here (no single edit or log action since December 2020). TranslationHelper did a great job on Meta but gradually fell inactive. Redmin said the bot is no longer need and as such it will be inactive and they are fine with removing the flag. However, void hasn't responded yet.
On a separate note, I am drafting an RFC related to user groups on meta that will cover the inactivity clause and other changes to user groups on Meta-Wiki. --Magogre (talk) 11:20, 6 February 2022 (UTC)[reply]
I'd be interested in contributing to a draft for this to clarify/combine language in certain areas. --Raidarr (talk) 11:56, 6 February 2022 (UTC)[reply]
Perhaps a discussion and vote can be made here on the Community portal to amend the bots policy to add an inactivity clause. For both bots in question, we can probably ask Void or Redmin if their bots still needs their flag. Agent Isai Talk to me! 04:33, 6 February 2022 (UTC)[reply]
Furthermore, the bot flag is requested via RfP, which is usually done via community voting. To remove it then you will have to do the same thing, to see the votes of the community. --YellowFrogger (talk) () 04:36, 6 February 2022 (UTC)[reply]
It is not necessary to request on RfP, policy doesn't say that anywhere, if I am not wrong. A discussion here would be valid too. --Magogre (talk) 04:42, 6 February 2022 (UTC)[reply]
So that's why Agent mentioned that you could implement a vote about bot inactivity, which interfered with these two bots mentioned by you. --YellowFrogger (talk) () 04:46, 6 February 2022 (UTC)[reply]
I'll leave both of them a note about their bots and this discussion. For the ammendment of policy, if anyone has any ideas they may start a discussion here or on RFC. Magogre (talk) 04:46, 6 February 2022 (UTC)[reply]
Even if there is no written policies about inactive bots in my view it is perfectly reasonable to request that a bot is removed by a bureaucrat if it has not been active in a long time and if the owner of the bot does not respond to messages. DeeM28 (talk) 05:30, 8 February 2022 (UTC)[reply]
Yes, that's what I was planning. It is clear that TranslationHelper isn't going to be active (confirmed by bot owner, though off-wiki) I don't know how to proceed with the Void-bot after they said they might need the bot for some purposes but not until May this year (though my personal preference is to remove the flag as they have to file the approval request anyway, it might be granted again if its task will be approved). Waiting for some other comments, if any, before requesting bureaucrats on Meta:AN to remove the rights. Magogre (talk) 06:00, 8 February 2022 (UTC)[reply]
Magogre, the Meta:Bots policy permits revocation by Meta bureaucrats for discretionary reasons. If the bots are not active on Meta Wiki, this would be reason for removal. The correct venue, however, would be to request revocation at Meta:Administrators' noticeboard. In fact, the two bots you mentioned have been on my "to do list" to request removal. I believe Void-bot may have had the bot flag on Meta Wiki for functionality it no longer has. Any user rights it needs for updating OAuth consumers and things are included within the confirmed group. As for TranslationHelper, it seems pretty evident it's no longer active here. In short, I concur completely with DeeM28 100% in that if revocation criteria is not specifically codified, removal is subject to the applicable user group's discretion, which, in this case, would be, principally, Meta bureaucrats. Dmehus (talk) 00:00, 13 February 2022 (UTC)[reply]
I've gone back though Void-bot's code, and I was honestly surprised to see that it hasn't needed to touch metawiki since at least early 2019. There may have been a few things since then, but yeah it does not seem to need the flag. I also don't think I'll be needing it any time soon, so it can probably be remove until I can come up with an actual reason to do something on Meta. -- Void Whispers 02:04, 13 February 2022 (UTC)[reply]
Thanks, Void. Yeah, if there's any missing OAuth-related user rights that should be added to the confirmed group, I think we can add them, but I'll link Reception123 to this thread when he's up. Dmehus (talk) 02:07, 13 February 2022 (UTC)[reply]
Both removed. Reception123 (talk) (C) 07:54, 13 February 2022 (UTC)[reply]

Is User:Anpang/Socks are stinky essay ready to go into mainspace

Is this in construction essay ready to go into the mainspace? It's still very short but I have seen many short essays in the mainspace before.  Anpang📨  04:08, 17 February 2022 (UTC)[reply]

No, I don't think so, but also, I don't see a problem with it remaining in your userspace. Not all essays, especially those with a somewhat humourous angle, should be in (Main) namespace. Areas to improve include the "how to a spot sockpuppet" section. "Requesting a CheckUser" should not be given as the first step in such cases. Overall, it needs more elucidation. Dmehus (talk) 04:10, 17 February 2022 (UTC)[reply]
I strongly agree with Doug here that leaving it in the userspace is both entirely acceptable and quite desirable in this case. Actually, one thought I've been musing is a dedicated Essay namespace, allowing subcategorizations including for humor and apparent consensus involved (the highest level on that ultimately just becoming a standard mainspace help page). Per topic though, its content is indeed quite slim.
What has been done in the past has largely been absent of an organized approach, so pages in the mainspace that are too short should be considered as well. This was an intention of the meta project that I've unfortunately fallen behind on pushing or acting for. --Raidarr (talk) Raidarr (talk) 12:21, 17 February 2022 (UTC)[reply]

2FA to be required for certain local Meta Interface rights

Meta Interface administrators,

Following concerns raised by a fellow Interface administrator, it will now be required that 2-factor authentication be enabled on your account to edit sitewide JavaScript and other user's personal JavaScript. This requirement will be enforced via our configuration and if you do not have 2FA enabled, you will lose access to editing JavaScript pages and other user's personal JavaScript but you will not lose the ability to edit sitewide CSS interface pages. This change will go into effect shortly. Thank you for your understanding. Agent Isai Talk to me! 19:53, 14 April 2022 (UTC)[reply]

This change requires consensus. I would most certainly be opposed to such a change. Also, JavaScript and CSS are treated the same. Naleksuh (talk) 16:55, 16 April 2022 (UTC)[reply]
It also appears this change was authored by a user who multiple people have advocated for removal of their SRE permissions in the past. Why are they now making extreme changes to the config without consensus? Naleksuh (talk) 17:00, 16 April 2022 (UTC)[reply]
Though I would've preferred that a community discussion taking place prior to implementation, it certainly doesn't need a Meta RfC. I suggested a short discussion at the talk page rather than here, so I'm not sure why Agent Isai posted it here. In any case, RhinosF1 has already implemented it in his SRE capacity. It applies only to Meta Wiki, and is a prudent best practice. Given that all existing Meta interface administrators are either (a) already required to have 2FA enabled as a result of certain global groups or (b) support the change (i.e., chrs, I think this is fine, so +1 from me as well. Dmehus (talk) 17:01, 16 April 2022 (UTC)[reply]
This doesn't appear to be implemented as I can still edit at - either the production deploy has not taken place yet or the unauthorized changes were reverted. Either way since I do not carry a smartphone this "security change" essentially disables interface admins, especially when this was just a random change with no related incident leading to it. Naleksuh (talk) 17:11, 16 April 2022 (UTC)[reply]
Naleksuh, firstly, as a security best practice, you should not be making sensitive changes to sitewide CSS and JS while mobile. Secondly, without a request from a Steward or a Meta bureaucrat, and typically following some sort of request Stewards' noticeboard or Meta:Administrators' noticeboard, as your role is a sub-delegated role of a Meta bureaucrat. As to your first point, looking at the LocalSettings.php history, it was not reverted, so it seems to have had no effect. Dmehus (talk) 17:17, 16 April 2022 (UTC)[reply]
you should not be making sensitive changes to sitewide CSS and JS while mobile Then you would support it being reverted, since this change means you must have a mobile phone with you in order to edit the CSS/JS. Naleksuh (talk) 17:19, 16 April 2022 (UTC)[reply]
I didn't say that, and where does it mean you must have a smartphone to edit CSS/JS? Dmehus (talk) 17:22, 16 April 2022 (UTC)[reply]
I do not see your edit ([[1]]), so it seems that it has been implemented. Dmehus (talk) 17:21, 16 April 2022 (UTC)[reply]
I didn't actually save anything beforehand, just looked at if I could view the edit screen. It does appear I can save though. However, that's not the important part. The important part is that this change was arbitrarily made and, while having no meaningful security benefit, does hinder interface admins ability to do their job (since I do not carry a mobile phone, this would mean me resigning as an interface admin). It was also made without consensus for it randomly by one particular person. Based on all of the above, this random, unauthorized, all-negative change should be reverted. Naleksuh (talk) 17:25, 16 April 2022 (UTC)[reply]

Draft proposal for Meta codification

As I have already set out in a previous Community Noticeboard post that was positively welcomed by Raidarr I have now created an initial draft proposal to codify some existing rules and conventions into policy here on Meta. I have explained there why I believe this is necessary to be done. I would like to invite all users that form part of the Meta community to add proposals that they think should be codified to achieve more clarity and to otherwise develop or improve the proposals I have already set out. If there are no additional proposals I intend to move the draft into RFC space in a few days but I hope that others will contribute to this draft. DeeM28 (talk) 17:31, 4 May 2022 (UTC)[reply]

This is sufficiently broad, open, yet also fundamental on meta that perhaps it would merit a sitenotice to collect input. Certainly when the proposal starts, but perhaps even in this stage. I'll probably have feedback on the wording soon in the meantime, either here or on the talk for the draft. --Raidarr (talk) 18:39, 4 May 2022 (UTC)[reply]
I've made a few changes to the wording but perhaps it can be improved even more. If there's not much activity a sitenotice during the drafting stage might be a good idea. Reception123 (talk) (C) 10:02, 5 May 2022 (UTC)[reply]
Added a short sitenotice for the draft itself. Reception123 (talk) (C) 06:54, 8 May 2022 (UTC)[reply]
This is a pretty good idea in terms of concepts (I do hope Dmehus makes an appearance today at some point, but it's like 3:36AM as of this writing in his area right now). DarkMatterMan4500 (talk) (contribs) 10:36, 8 May 2022 (UTC)[reply]
I don't really understand the idea behind continuing to edit the draft and even in doing so changing what the RfC is. Obviously I will be opposing 1 and 4, but what good would editing the RfC do? So people can edit them or remove them? Naleksuh (talk) 18:00, 8 May 2022 (UTC)[reply]
While reviewing the Community portal archives, I stumbled upon this thread made by Recepetion123 in which he proposes the codification of a "main policy" of which the draft is located at Meta:Main policy/Draft. The draft mentions 2 things that may seem trivial to us but perhaps would be useful in codifying such as what is on topic for Miraheze Meta. By convention, we delete pages that don't directly relate to Miraheze or Meta (i.e. pages for wikis, etc.) but this isn't codified (as far as I can see) so would codifying that perhaps be useful too? Agent Isai Talk to me! 01:23, 9 May 2022 (UTC)[reply]
As far as this conversation of "codification" has been going on for some time, I'm not all that convinced that Meta conventions are consistent enough to reliably document and codify any standards at this time. Meta has realistically failed to develop any sort of "community" and has become stuck as a procedural hub. I think it is for this reason that Meta does not see the engagement necessary for observable trends, standards, and expectations to take hold in any form of a code. As anxiety inducing as it can be, the current "flow state" of community (dis)approval toward administrative actions is probably the best possible space for Meta to exist right now. dross (tcg) 07:19, 9 May 2022 (UTC)[reply]
I also meant to note in this that Meta has proven itself to be very fluid. Users not only come and go, but every group of users to inhabit Meta so far have proven to possess entirely different cultures. Meta has always changed with these users. Codifying standards in the current state where turbulence is the norm would create additional unnecessary bureaucracy to the processes which exist here. dross (tcg) 07:31, 9 May 2022 (UTC)[reply]
I agree with Dross that unfortunately Meta has not developed a 'community' per se, and that's a shame. At the same time though, while I don't think we need to codify everything some particularly controversial things need have clear community endorsement in order to stop repeated arguments taking place about whether they're convention or not. If there's no interest to codify any other things, I would personally think it would be good to proceed with the RfC as it currently is to at least codify these principles which have proven to be controversial and in dispute. Reception123 (talk) (C) 10:51, 9 May 2022 (UTC)[reply]