Wikipedia:Village pump (idea lab)

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
 Policy Technical Proposals Idea lab Miscellaneous 
The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas.
Before creating a new section, please note:

Before commenting, note:

  • This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them.
  • Wondering whether someone already had this idea? Search the archives below, and look through Wikipedia:Perennial proposals.
« Archives, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29


Drafting a partial blocks RfC[edit]

A few weeks ago, I started a discussion on MusikAnimal's talk page regarding partial blocks and whether the English Wikipedia had any interest in adopting this feature. As a result of the discussion, I created a draft RfC which is now at Wikipedia:Requests for comment/Partial blocks. I wanted to push this here to get more input on the draft. Is the format too messy? For "Option B", the limited implementation, should we include more subcases to start? Should we allow users to add their own suggested subcases during the RfC? Mz7 (talk) 21:35, 10 April 2019 (UTC)

@Amorymeltzer: In response to your question re. enforcing vs. recording editing restrictions, I was mostly trying to put into word the proposal about recording restrictions that MusikAnimal had suggested – presumably part of the purpose would be to help enforce editing restrictions, with the caveat that the restriction might apply to pages not covered by the block. I've added the word "enforcing" to B.3 to clarify this. Mz7 (talk) 21:39, 10 April 2019 (UTC)
I would like to ping SPoore (WMF) to this discussion, since she has information about how other Wikipedia (e.g. Italian Wikipedia) have used partial blocks. Perhaps we might choose to follow the lead of other projects in deciding how to implement this. Mz7 (talk) 21:39, 10 April 2019 (UTC)
Mz7, I'm working on getting metrics and use cases for partial blocks for the wikis that are using them now during the testing phase. SPoore (WMF), Strategist, Community health initiative (talk) 20:00, 15 April 2019 (UTC)
What would the most common use cases for admins be if they had free-reign (Option C)? Tazerdadog (talk) 00:00, 11 April 2019 (UTC)
It seems to me that the way you've structured the RFC with respect to option B would get messy quick. I think as the RFC progresses people would add more use cases to B, and people who !vote early on may not come back to evaluate the later added options. It might be better to make it a two part RFC, and if option B (allow partial blocks in specific use cases) passes, then have a second RFC on what use cases people want. While discussion of the first part progresses, there should be a sub section for discussion (but not !voting) of possible use cases to be added to the second part. ~ ONUnicorn(Talk|Contribs)problem solving 16:21, 12 April 2019 (UTC)
@ONUnicorn: Right, I had that thought as well. Your two-parter RfC idea did cross my mind, and I think I will change the draft to that format. Thanks! Mz7 (talk) 02:05, 13 April 2019 (UTC)
I don't know if Sydney's got all the information together, but I hear that there are some cultural differences, partly based on how a community feels about blocking established editors/vested contributors. At some wikis, blocking a "regular", regardless of how bad the behavior is, brings down wrath on the admin, because now there will be a permanent badge of shame in the user's block log. Blocking anyone except newbies is seen at some wikis as an insult, rather than a technical means to interrupt some bad behavior. But since what they're calling "partial blocks" aren't regular blocks, and therefore aren't recorded in the regular Special:Log/block, some communities feel like this is a more appropriate way to deal with established editors – more like a technical way of saying "Hey, we like having you here overall, but you need to take a break from this particular page for a couple of days".
I don't know that we'd see the same dynamic in this community, but I think that team will have interesting things to say as they analyze what's been going on. Whatamidoing (WMF) (talk) 19:25, 23 April 2019 (UTC)
@Whatamidoing (WMF): I'm not sure I understand. The current guidance seems to indicate that these are recorded in the block log as normal. GMGtalk 11:00, 1 May 2019 (UTC)
I'm sure that it's logged somewhere, but I can't find any specifically in Special:Log/block. The feature's under active development, so they may have tried different things at different times. Whatamidoing (WMF) (talk) 15:18, 3 May 2019 (UTC)
Not sure if this is off-topic or not, but is it technically possible to block a user from editing a page and all its subpages, or pages that contain a particular string in their names? For example, would it be possible to block a user from editing all subpages of Wikipedia:Articles for deletion? feminist (talk) 10:26, 29 April 2019 (UTC)
@Mz7: does this feature allow an admin to block a user from editing a particular set of pages (subpages, etc.)? feminist (talk) 10:03, 1 May 2019 (UTC)
@Feminist: As far as I am aware, partial blocks only prevent editing on specific pages – I don't think you can block the user from a set of subpages, but you can block access to namespaces (e.g. can't edit articles, but can edit talk pages). Adding the ability to block over subpages sounds like something we can suggest to the developers of the feature if it is something we're interested in. Mz7 (talk) 21:37, 1 May 2019 (UTC)
OK then. It seems like an important feature to me, e.g. if someone is problematic at AfD we should be able to block her from editing AfD discussions, while continuing to allow her to edit, say, RFPP. But what we have is better than nothing. feminist (talk) 05:21, 2 May 2019 (UTC)
  • As a variant of B, can we have as an option preventing the use of them under WP:DS? As its not a current power, I don't feel we're revoking any authority that would otherwise require another ARBCOM amendment. I very strongly agree that B should be done in a distinct RfC - this is just a suggestion for "if and when B is selected" Nosebagbear (talk) 21:53, 1 May 2019 (UTC)
    • Maybe some day, but not yet. One of the ideas is to allow partial blocks to operate via categories. The use cases look something like:
      • Keep the editor out of 1 to 10 named pages (currently available) – good for routine disputes.
      • Keep the editor out of this namespace – imagine being able to block a paid editor from the mainspace entirely, or stopping someone from breaking templates.
      • Keep the editor out of a large group of pages – routine POV pushing across more than 10 pages or imposing discretionary sanctions.
    • The last one is the category idea. You could create hidden categories for each of the ArbCom discretionary sanctions areas, or a specific list for an individual, and block the user from anything in that category. You'd have to watch additions/removals from the cats closely, but there are tools to do that, and it might reduce the number of problems with accidental TBAN violations (e.g., if a subject is connected to the TBAN area, but the connection is not apparent to the editor). Whatamidoing (WMF) (talk) 15:30, 3 May 2019 (UTC)
  • @Mz7: - in your initial discussion you raised basing it off the ECP discussions board (which seems reasonable enough). Having read that, since it predates my active existence by 19 months, the closer mentioned an ECP review to take place 3 months after. Did that occur? And in either case, I would say a 3 month review to discuss how it was working would seem wise here, too. (I don't mean on the ACTRIAL/ACPERM level of requiring re-authorisation, just a mandated discussion of how it was working for en.wiki). Nosebagbear (talk) 14:13, 5 May 2019 (UTC)
    Nosebagbear, I'm not sure whether the specific ECP review that was mentioned in the closing statement was ever conducted, but there have been several discussions since then about the role of ECP if you scroll through the archives of WT:PP. We also had a follow-up RfC that proposed expanding the scope of ECP at Wikipedia:Requests for comment/Extended confirmed protection policy 2. Going back to partial blocks, I would be unopposed to a review after 3 months to evaluate how it's going. Mz7 (talk) 20:34, 6 May 2019 (UTC)
  • Comment - timed article t-bans work and serve the same cool-down purpose. Unfortunately, we now have admins using sole discretion to impose indefs and broadly construed t-bans. I'm not convinced that doing so best serves the project. When there is edit warring, and/or disruptive behavior on an article TP, all of the involved edit warriors/disruptors (be it 2 or 5+) should receive the same t-ban. Doing so further relieves the acting admin of having to choose sides or delve into content issues that spawned the disruption and eliminates any appearance of bias on behalf of the admin, perceived or otherwise. It will also encourage a more collegial environment. Atsme Talk 📧 11:03, 23 May 2019 (UTC)
  • Personally, I think we can experiment, and use the RFC to discuss best practices. By experimenting we can see where the tool would become useful in practice, and we can make changes and discussion and understand the logic behind the admin and the feedback from the target and other editors. I have been waiting a while for something like this (partly because historically I have caused problems that could have been stopped with a partial block, and partly because I see full blocks as an invitation to create sockpuppets that last for years such as User:Scibaby), and I think the RfC should have a few sections:
  • no partial blocks, full blocks only
  • partial blocks only by arbitration decision
  • partial blocks only by either arbitration decision or community consensus
  • partial blocks only when an editor has been edit warring (in addition to ArbCom and CBAN)
  • partial blocks when an administrator has determined that a full block may cause more problems, such as sockpuppetry or WP:DONTBITE.
I would also have a section designed to formulate the partial block message which can be commented on by community consensus (relevant interface pages include MediaWiki:blocked-email-user and MediaWiki:blockedtext-partial). But I have been waiting for something like this because sometimes full blocks may not be super appropriate. If a user only causes disruption to Wikipedia processes, only block them from the Project: namespace. If a user makes bogus edit requests, only block them from talk pages. If a user cannot stop criticizing Donald Trump, only block them from Donald Trump and related pages. Full blocks prevent otherwise useful edits elsewhere from happening, and that is why I see this RFC as important.
I also have a question: when will this RFC open? Awesome Aasim 05:49, 3 June 2019 (UTC)
Currently we are still waiting for SPoore (WMF) to send over her research on how this functionality is being used on other projects, but I recognize that it has been several months now since we started talking about this. I'm thinking we'll start the RfC "sometime this summer", maybe in July if SPoore hasn't gotten back to us by then. I'm also starting to dislike the current structure I have for the RfC (see Wikipedia:Requests for comment/Partial blocks). Maybe the RfC should be in two phases: phase 1 would be "yes" or "no" to "should we enable partial blocks?", and phase 2 would be "what restrictions, if any, should we place?". Mz7 (talk) 20:06, 10 June 2019 (UTC)
  • @Mz7: - that all seems reasonable, both in terms of timing and split of RfC. July seems a good wait - partial blocks are currently getting an unfair blowback from the Fram saga, and it'd be nice to give them a fair hearing. Do we need extra discussion about the specific options for the "what restrictions" bit? Should that be now, or, if/when it's conceptually passed, we ask editors to suggest what they'd like to see? Nosebagbear (talk) 20:56, 15 June 2019 (UTC)

Google Doodles[edit]

Is there some way that we could learn about Google Doodles before the day on which they will occur in order to improve the articles? StudiesWorld (talk) 13:45, 10 May 2019 (UTC)

You know they differ depending on your location and there's not some standard global calendar they follow, right? I can't imagine they would ever agree to it; giving pre-notification of what they plan to run would mean Google opening the floodgates for every spammer and SEO-merchant to crapflood them. ‑ Iridescent 13:56, 10 May 2019 (UTC)
Alternately, perhaps Google would consider improving the articles themselves while creating the Doodles? A lot of their value is in visitors' ability to discover context by clicking through to a free article explaining the subject. – Teratix 14:20, 10 May 2019 (UTC)
@Teratix: - that wouldn't work either. They'd be paid editors that people would eventually catch on edited the doodles pre-emptively. Or they'd need to create a bunch of one-time accounts...which is also not something we'd want to encourage in paid editors Nosebagbear (talk) 18:08, 10 May 2019 (UTC)
I don't see anything inherently wrong in creating many one-time accounts for this purpose, as long as they declared their paid status and connection. They would be benevolent paid editors, not harmful. Alternatively, if we want to restrict them to one account but avoid giving the game away early, Google could prepare an updated version of the article but only post it once a Doodle was live. Of course, this is assuming Google wants to take the time to do this, which may be doubtful. Still, it's worth asking the question. – Teratix 18:28, 11 May 2019 (UTC)
@Nosebagbear: I think it could actually make sense, even if people would catch on the day before, because we still wouldn't know what the Doodles would look like, and part of the interest in them is because they're sometimes interactive or otherwise interesting in some way not derived from their being labelled Google Doodles. It also wouldn't be especially surprising if, for example, they were to improve Saint Patrick's Day and related articles every March. It would also serve as a way for Google to "give back" other than sending the WMF piles of cash. Jc86035 (talk) 11:01, 14 May 2019 (UTC)
  • Unless one actually worked for Google, how would one know what the Google doodles were the day before they occurred? Vorbee (talk) 17:22, 22 May 2019 (UTC)
  • @Vorbee, as I read it the proposal is that we pay (or encourage) Google themselves to write articles on the relevant topics before the Doodles run. Needless to say, if we actually did catch Google trying to influence our content that directly, we'd block the accounts on sight. ‑ Iridescent 18:16, 22 May 2019 (UTC)

Whilst a Google Doodle briefly increases traffic to a Wikipedia subject page, I dislike a subject page being edited to state something like "on such and such date this person/thing was honored by a Google Doodle". For example, as I'm writing, the Google Doodle is on Elena Cornaro Piscopia, and on her page under "Legacy" it says "On 5 June, 2019, Google celebrated her 373rd birthday with a Google Doodle.", so what. Likewise, for Ada Lovelace under "In popular culture" it states "In 2017, a Google Doodle honored her on International Women's Day." It adds no value to any article. For me, these entries are just spam. It isn't notable that, for a short period, a search engine briefly acknowledges a person or subject, therefore it should not be in a subject's Wikipedia page. This topic has been mentioned before, see Wikipedia:Village_pump_(policy)/Archive_119#Welcome_or_reject_mention_of_Google_doodles_throughout_the_encyclopaedia?, and the few comments generally agree with my view. I would like to see a policy where adding an entry to a subject stating that it was briefly mentioned as a Google Doodle be disallowed, and when we come across such a mention it can be removed.GR8DAN (talk) 12:38, 5 June 2019 (UTC)

I note that Wikidata has a property for recording Google Doodles. (See http://w.wiki/4eg for examples.) Perhaps we should divert the efforts of google-doodle-recorders over there. This gives us the option to display Google Doodle links automatically in infoboxes or whatever, depending on local policy. Bovlb (talk) 17:45, 5 June 2019 (UTC)

Yet another Main Page redesign proposal[edit]

I have created a draft of a Main Page redesign that can be seen here, even though I know redesigns are rarely sucessful. It is by no means meant to be a final design, but maybe it could serve as a starting point for some discussion. There are certainly areas that are up for debate or could be refined. Feel free to give some input, or use as basis for other suggestions. -- Jsdo1980 (talk) 11:21, 19 May 2019 (UTC)

Well, I like it—personally I think the small color palette is more consistent with the rest of Wikipedia. It should definitely be reflowable, though (i.e., shrinking the browser window size should switch it to a one-column layout). Also, I think the (for want of a better word) looming puzzle ball looks redundant with the logo being in the sidebar and all. Eman235/talk 12:10, 19 May 2019 (UTC)
Reflowable is a good suggestion, that would be good. I also agree somewhat with the logo as background as well, I just felt that the header area looked empty. Maybe some other backround could work? -- Jsdo1980 (talk) 12:44, 19 May 2019 (UTC)
I've added another more generic background. -- Jsdo1980 (talk) 14:34, 19 May 2019 (UTC)
Ooh, I like that; it's reminiscent of Monobook. Eman235/talk 19:02, 19 May 2019 (UTC)
Yeah, I like the simple palette and the larger spacing around the text, but I'm not sure it's sufficiently better than the current design to justify the endless discussion and editor hours that would be spent evaluating and implementing the new design. There is a reason there hasn't been a redesign since 2006. – Teratix 13:46, 19 May 2019 (UTC)
Yeah, I've noticed that it's no easy task... I would however say it might be worth it. - Jsdo1980 (talk) 14:34, 19 May 2019 (UTC)
I think you need a little more margin/padding around the labels - for example the "Today's featured picture" text is abutting/being partially obscured by the image below. — xaosflux Talk 17:42, 19 May 2019 (UTC)
In monobook at least. For the same section in minerva, the image so tiny it is hard to see. Try out any workups with all the skins to make sure they work well. — xaosflux Talk 17:43, 19 May 2019 (UTC)
Good point. Vector has increased the line height. I've tried to fix that. Does it look better now? -- Jsdo1980 (talk) 18:06, 19 May 2019 (UTC)
Better, note TFP looks bad in minerva. — xaosflux Talk 23:51, 19 May 2019 (UTC)
TFP looks bad in Minerva with the current design as well. I'm using the same template, so I can't change that. -- Jsdo1980 (talk) 13:08, 20 May 2019 (UTC)
  • Well, I think the header is at least better than what we have now. It looks quite more modern. – Ammarpad (talk) 15:53, 20 May 2019 (UTC)
I don't have any specific suggestions, but wanted to say that I like it better than the current main page. Good work. Levivich 03:15, 22 May 2019 (UTC)
  • @Jsdo1980: If you use TemplateStyles you can do cool stuff like making the content responsive. I think it already looks nice but would agree that it's not yet enough of an improvement to justify replacing the current main page. (Also, it's probably better not to specify Arial specifically, since most of the skins don't use it as the default font. You should probably leave font selection to the website's CSS.) Jc86035 (talk) 10:47, 22 May 2019 (UTC)
Jsdo1980, considering that the last attempt at making a change (non-visual) to the main page was reverted because someone with a tiny screen laptop 'suddenly' had 1 column instead of 2 columns, I'd say, be prepared to engage for a long time and to face stiff opposition if you want to make a change. I'm personally pretty done with trying to get anything moving on the main page, the community is just too stuck in their ways. —TheDJ (talkcontribs) 11:24, 22 May 2019 (UTC)
  • I really like it. Especially the borderless sections and the headings. It's on a par with the Russian and Spanish main pages which are probably my favourite out of the existing versions (this 2014 proposal is also quite nice). As for subjective aesthetic criticism, the only things I'm not sure about are the gradients in the bordered boxes which are gradual enough that it makes it look a bit like they're just filled with differently coloured rectangles, the right-hand side (the non-book bit) of the main banner's background image which you could argue takes away from the simplicity,[1] and possibly the portals bar, though it's growing on me. I think it's that it looks a bit out of place since there are no other blue bits or fade-out gradients. (Personally, I'd get rid of the portals altogether.) ─ ReconditeRodent « talk · contribs » 22:52, 5 June 2019 (UTC)
  • I think that this new mainpage design looks nice. Personally, it looks a lot better than the current one. This new design is a lot cleaner and simpler. Especially seeing as the current design uses many different colours and is filled with many boxes. I agree with ReconditeRodent that the portal bar is a bit different from everything else. Personally, I would not be opposed to moving these links down the page, however, if the links are going to stay in their current location, I would want them too not stand out as much. Dreamy Jazz 🎷 talk to me | my contributions 10:18, 7 June 2019 (UTC)
    @ReconditeRodent and Dreamy Jazz: Thanks! I've made an alternate version where I have removed the gradients and replaced the portal bar with an "information bar" to the right, and moved portal contets to a section at the bottom instead. I've used the subportals or related portals for the old portals. In some cases it becomes a bit weird in my opinion, like for Biography. -- Jsdo1980 (talk) 12:08, 8 June 2019 (UTC)
    Jsdo1980, I like that version even better. I think having links to the Wikipedia introduction, help pages and contact page at the top of the main page will help to make the main page more accessible for new users.
    One thing, there a good number of portals you have placed in the portals section. I would say that with the recent controversy of single page portals based on navboxes, links to portals based on navboxes won't be accepted by the community. From what I can see you have only linked maintained / non-navbox based portals. (For your interest you can see Wikipedia:Miscellany for deletion/Mass-created portals based on a single navbox and Wikipedia:Miscellany for deletion/Second batch of mass-created portals based on a single navbox). Dreamy Jazz 🎷 talk to me | my contributions 12:39, 8 June 2019 (UTC)
    @Dreamy Jazz: I was not aware of that. Thanks for the heads-up. -- Jsdo1980 (talk) 15:35, 8 June 2019 (UTC)

References

  1. ^ Turns out it is a book, not a photoshopped-in text editor, and I'm an idiot. Might even prefer it over File:Wikipedia logo letters banner.svg for the gorgeous paintbrush effect by the welcome message but I'm happy either way.
  • @ReconditeRodent: I edited the alternate version to see how it looked with File:Wikipedia logo letters banner.svg. I kind of like that as well. Had not seen the Russian and Spanish main pages before. -- Jsdo1980 (talk) 15:35, 8 June 2019 (UTC)
  • It might be good actually if there's a way for the welcome message and the date to stack if the window is resized and they would overlap. (It shouldn't be a massive problem though since presumably the mobile version will stay the same.) ─ ReconditeRodent « talk · contribs » 15:58, 8 June 2019 (UTC)
    Yeah that would be great. Or maybe even better if the right element is hidded if there is an overlap. This is a test design, so currently it doesn't seem possible due to all the overlapping elements in the banner (the background and the gradient), meaning I'm forced to use the position property. I'm sadly not proficient enough to know how to solve that. -- Jsdo1980 (talk) 18:04, 8 June 2019 (UTC)
    Jsdo1980, you could use @media styles. (i.e. under a certain width you could say that other styles apply). For example, you could set bottom:0; (and remove top:0;) the statistics part of the welcome message and increase the height of the welcome message.
    For example (illustrative only):
    @media all and (max-width: 334px) {
    #welcome-message-statistics {
    top:auto;
    bottom:0;
    }
    #welcome-message {
    height:12em;
    }
    }
    I got a working draft version using chrome's inspect element. It is supported by virtually all browsers (minus IE <9) (caniuse statistics). Bearing in mind that this would only be used if the screen was made very narrow and wouldn't affect anything if the browser is less than IE 9, I suspect that the issue with pre IE 9 support won't be a big deal. There may be other ways to deal with this, but this is the first one that popped into mind. Dreamy Jazz 🎷 talk to me | my contributions 21:57, 8 June 2019 (UTC)
  • I don't view or use the Main Page much, but I'm neutral to mildly positive on the new design. My only complaint is that I dislike the pale blue gradient near the top. Alsee (talk) 01:06, 9 June 2019 (UTC)
  • Comment. I really like this. Good job so far, Jsdo1980!! I hope you have received the constructive feedback you were looking for as well. If you continue with this proposal elsewhere, please ping me. Face-smile.svgMJLTalk 02:45, 10 June 2019 (UTC)
    Oh, I do like that you include the time top-right corner (I kid you not; I sometimes make edits just to figure out what time it is here.. this would be a lifesaver), but I suggest that maybe it not be linked and be appended (UTC) just like in a signature (ie. no periods). Readers might get confused otherwise, and if we link them then suddenly Monday will get a spike in views that we really aren't equipped to deal with. –MJLTalk 02:49, 10 June 2019 (UTC)
@MJL: The second box under Preferences -> Gadgets -> Appearance has the option to display the UTC time by the user buttons. Might be useful. -A lainsane (Channel 2) 03:03, 10 June 2019 (UTC)
@A lad insane: I appreciate the suggestion! –MJLTalk 03:09, 10 June 2019 (UTC)

AWB-alternatives for Linux[edit]

Is there any alternative of AWB for linux? Now AWB can run through Wine. But it may not support in all systems. Other AWB-like softwares such as PyAWB, JWB, etc are not working currently (correctly). It is better that creating a linux/mac supporting versions for AWB like huggle 3, huggle version which is compatible for linux also. It will help Linux/Mac using Wikipedians for using AWB more efficiently. Thank you.--PATH SLOPU 03:07, 28 May 2019 (UTC)

AWB is a pretty complex piece of software bundling a lot of functionality. Is there a particular feature or set of feature(s) you were interested in? -FASTILY 04:17, 3 June 2019 (UTC)
@Fastily:I interested it's features such as doing repetitive edits in in a set of pages. For example adding a particular text, template, etc in several articles. Creating a set of new articles (usually stubs) of on topics such as places, geo-features, etc. Thank you.--PATH SLOPU 07:15, 3 June 2019 (UTC)

At one time I used AWB on Windows with programs in Unix (linux). Basically AWB does all the login authentication and uploading diffs, while the core logic is done under unix via AWB external script function. It can be done with Cygwin, or virtual box. More info User:GreenC/awb/cygwin. AWB runs under windows natively and the bot program runs under Unix natively, best of both worlds. -- GreenC 14:39, 3 June 2019 (UTC)

@GreenC:But this is done in a shared system, isn't it? Regards.--PATH SLOPU 15:54, 4 June 2019 (UTC)
A virtual machine. Linux can be guest and windows as host, or other way around. In my experience there is no performance or other problem with decent CPU and memory. VMs are quite common even at Wikipedia, most hosting providers, Amazon etc.. -- GreenC 16:07, 4 June 2019 (UTC)
BTW so long as the Windows and Linux machine share a common folder such as with network attached storage they don't need to be hosted on the same computer. -- GreenC 16:12, 4 June 2019 (UTC)
@GreenC:Thank you for advice. But it means the users must need a Windows system, mustn't it? Regards.--PATH SLOPU 15:49, 5 June 2019 (UTC)
I don't think there are any plans at the moment to make a cross-platform AWB. (Incidentally, what issues are you having with JWB? You might want to bring that up here.) But it is freely licensed, so anyone with the ability and initiative could modify (or rewrite, which is what I think happened with Huggle 3) the code to run cross-platform. Eman235/talk 03:29, 6 June 2019 (UTC)

The possibilities of a custom magic word variable to get the number of watchers on a page[edit]

I recently discovered {{User Centijimbo calculator}}. I assumed that it could automatically calculate the number of Centijimbo's a person had, but this was not the case. I discovered that to keep templates such as this one up to date, an editor has to periodically update the number of watchers on Jimbo Wales userpage. It also requires editors who use the templates to update the number of watchers on their userpage periodically.

An idea I have to alleviate the amount of maintenance needed for these templates is, to either add a new magic word variable into mediawiki or define a custom magic word variable for enwiki, which could return the number of watchers for the current page or a specific page. I envisage this would work similarly to the magic word variable {{PAGEID}} which either returns the current page's ID or the ID of a named page. This magic word may have more applications than just keeping a users Centijimbo count up to date, however, currently I am unsure what else it could be used for. I would appreciate any opinions and thoughts on this idea, including other ways such a magic word variable could be used. Thanks, Dreamy Jazz 🎷 talk to me | my contributions 10:08, 7 June 2019 (UTC)

What conceivable use could this have other than to allow a handful of WP:NOTHERE types to goof around with userboxes? (The userbox you mention is currently used by a total of four people.) I struggle to think of any legitimate reason for ever wanting to know that the number of watchers of any given page has changed; there's arguably a case that on a handful of topics it might be useful to track spikes in the numbers of watchers over time, but those would be vanishingly rare as the pageview numbers will almost invariably be a better indicator of levels of interest (the majority of watchers of any given page are virtually without exception long-departed accounts which never unwatched the page before they retired or were blocked). ‑ Iridescent 10:14, 7 June 2019 (UTC)
Iridescent, there are other templates. The most popular (I think) is User:Audacity/centijimbo (however this only has 149 uses). I do see that this magic word variable would have little use apart from counting Centijimbo's. Thanks, Dreamy Jazz 🎷 talk to me | my contributions 10:22, 7 June 2019 (UTC)
Indeed, and Template:Annual readership (and the like) covers any relevant uses of page views, which is as you mention the more interesting and useful metric. Watchers are vanity, pageviews are coverage. ~ Amory (utc) 11:00, 16 June 2019 (UTC)

Button for the opposite of "minor" edit?[edit]

I suspect something like this has probably been proposed before, but I couldn't find it.

The "minor" button is useful for editors to flag their edit to be (in their opinion) unlikely to be of interest to other editors to review. That helps other editors focus their efforts elsewhere, where it's more likely to do some good. It's a great button (except when misused, but that's a different subject).

Now, how about the opposite? I make an edit that's a needed improvement, well and good, but compared to average kind of changes I make, rather than unlikely, I think this is one more likely to benefit from review. Maybe it's a bit complicated, might have some possible consequences or side-effects, or maybe it could be just a start for other editors to come and expand upon.

Okay, "that's what the talk page is for", I'd bet I'd hear. From what I've seen on talk pages, almost all the sections (except for bot-generated ones) are about issues that demand discussion. I don't see how there's an obvious bright line between those issues that absolutely need discussion and those that don't; so it seems we err on the side of not discussing things on talk pages. That's understandable; no one wants to go through the whole process of formalizing a new discussion on the talk page, just to find that (as they suspected but weren't certain) no other editor finds its worthy of any notable response. Talk pages are basically used as the last resort for editing, and I wouldn't change that. I'm sure we don't want to try forcing editors to start more discussions on the talk page when they may not be needed; that's a lot of additional effort, and the talk page would get cluttered with unimportant issues obscuring the important ones.

This button fills the gap between those edits requiring discussion and those that might benefit from it. The editor clicks this button on their edit of interest, and if any other editor, seeing the button's tag on the edit, reviews it and thinks it should be discussed, they can start a discussion, knowing for certain that there's a discussion to be had. If none do, everyone's happy, and there was no wasted effort.

Although the opposite of "minor", rather than calling this proposed button "major", I think I'd go for something like "interesting".

And, interestingly enough, this could be the default button for all new users. After the user has become savvy enough to know how and why, the user can remove this default setting in preferences.

Oh, and at least some of that bot-generated discussion clutter could be eliminated by those bots simply using this button instead.

--A D Monroe III(talk) 22:45, 14 June 2019 (UTC)

@A D Monroe III: can you describe the problem you are seeing with bots a bit more? Bots can already pick normal/minor AND bot/not-bot flags on each edit. Most routine bot edits are marked 'bot' already to avoid bothering watchlists and recent changes. — xaosflux Talk 23:07, 14 June 2019 (UTC)
I don't have any problem with bots that warrant specific attention; I only mentioned bots here as sort of an allegory. But since I mentioned bots, I'll respond, but I don't want this whole idea to center on bots; this button's value isn't based on bots.
Yes, bots can and do use the "minor" or "bot" flags, and that's fine. The "bot" flag means "automated edit", and the "minor" flag means "small and obvious change", with both indicating less review is needed. But, again, I'm talking about the opposite kind of edit. Say there's a bot that, despite its excellent massive contributions, can sometimes cause additional work to be done depending on the article's current detailed context, which only the article's current editors can know. So the bot must alert those humans to review its work. This is currently done by the bot adding a new section to the talk page. (Being bots, their template-driven context-free overly-formal talk page entries, by necessity, are... um... let's say "less than thrilling".) Only a couple bots now running do this; I suspect there could be more bots like this, but we're reluctant to have a lot of bots cluttering talk pages, so we reluctantly decide to not let them run, loosing their potential great mass of good contributions. But this new button could do much of the same job to urge review without the annoying talk page clutter. More bots!
(I haven't heard of this, but guess that a bot that uses "bot" flag but not the "minor" flag could be interpreted as "please review this bot's edit". Is that true? If so, great, we should announce this better, but more importantly, where's my button for the same thing?)
Again, bots are not the main point here; I bought it up as an example of the kind of edit that could use this new button. --A D Monroe III(talk) 15:13, 15 June 2019 (UTC)
@A D Monroe III: thanks for the updates, just looking for ways we can improve bot interactions even if this doesn't go anywhere. In general bots making content-related edits that should be reviewed should not use the "bot" flag on that edit. These should be uncommon at best, but if you have some good examples we can look at that behavior (and feel free to bring it up at WP:BOTN. — xaosflux Talk 16:43, 15 June 2019 (UTC)
(edit conflict) Not a bad idea, but what is wrong with putting something to the effect of "please review" in the edit summary? There's also the mw:ORES review tool, which flags "potentially damaging" edits. Eman235/talk 23:11, 14 June 2019 (UTC)
("Potentially damaging" is, I hope, not applicable to an "opposite of minor" edit; I don't think editors should be encouraged to have their edits cross this line just to get some attention.)
I agree that edit summaries are the best way to do this right now. Edit summaries are limited, so this works best if the indication is terse, right? To be most effective, we could advise people to have the edit summary include the phrase "please review" (as suggested) or "interesting" or whatever we decide. If we go that way, to be sure they get it correct, we should have some way to have this phrase generation automated, like with a button. And then we could have reviewing tools search for this exact phrase.
Taken together, that's identical to my proposal here. I think a tag is better than a phrase, though. But, maybe we could start implementing this by just a new guideline on edit summaries? --A D Monroe III(talk) 15:45, 15 June 2019 (UTC)
  • Don't we already have the opposite of "This is a minor edit" with the "Watch this page" box? Vorbee (talk) 15:03, 16 June 2019 (UTC)
Watchlist is similar, but it works the other way around. Putting something on my watchlist means I want to review other editors' changes. If I want other editors to review my edits, I can't force it onto others' watchlists[a]. And, watchlist is per page, not per edit. --A D Monroe III(talk) 14:32, 17 June 2019 (UTC)
  • Is it possible to mark content which changes a fair percentage of an article as major automatically? I think as we already have the diff size, this could be easily done by tweaking the ui. Viztor (talk) 21:23, 16 June 2019 (UTC)
We kind of have a weak version of this already, as edit history gives the size of each edit (it's the delta size, so not perfect in this respect). I'm okay with enhancing tools to automate finding edits to review based on various criteria, but that wouldn't address what I'm asking for here. I want a tag that I decide to attach to one my own edits, indicating that despite any and all superficial characteristics of this edit, it still might be good for others to double-check it. --A D Monroe III(talk) 15:07, 17 June 2019 (UTC)
  1. ^ Do not think of implementing forcing additions to others' watchlists as a feature! I mean it! Stop those thoughts NOW! Bad, BAD idea! No biscuit!