Wikipedia

Wikipedia talk:WikiProject Portals/Archive 11

< Wikipedia talk:WikiProject Portals
Latest comment: 4 years ago by BrownHairedGirl in topic A milestone: less than 1500 portals
Archive 5 ← Archive 9 Archive 10 Archive 11 Archive 12 Archive 13 → Archive 15

Proposing two-stage process for deletion of portals

Latest comment: 4 years ago13 comments5 people in discussion

I've mentioned this in several places, but I'd like to propose formally that this project institutes a two-stage process for the deletion of portals. This would apply to old portals (pre-dating the "End Portals" RfC of last year), whether or not they had been converted to the automated format. I don't envisage it applying to any brand-new portal without history, nor to the remaining navbox-, list- or outline-based automated portals, which are generally easy to assess and difficult to improve without essentially starting from scratch. Portals that urgently need deleting for any reason (I'm thinking of BLP violations in particular) would also be excluded. It might also exclude portals on a truly miniscule article base. The process would be optional, but a reasonable argument for retention at Miscellany for Deletion would become that the nominator should have taken it to Portals for Discussion (or whatever) first.

I envisage this working a little like the now-defunct portal peer review, and it could form a sub-part of a revival of that process. The nominator would identify a substandard portal, and would bring it to the forum. They would notify all interested parties, including creator, maintainer and relevant Wikiprojects. The focus of the nomination would be on the ways in which the portal needed to be improved in order to be more useful to readers. Nominations would not usually be batched. Everyone would be encouraged to critique, bluntly if necessary, but also to help out in improving the portal. The process would last longer than the MfD cycle, perhaps a month, or even longer if the portal was still being improved. At the end of this time, either the original nominator, or perhaps a co-ordinator, or another uninvolved project member, would either (1) declare the portal adequately improved; or (2) move to a MfD deletion request, which would proceed in the usual fashion.

The advantages I see for this process include:

  • it would be less confrontational and more collaborative
  • plenty of time would be allowed to find maintainers and improvers, and to get collaborations going, and there would be no artificial time cut-off imposed
  • novel solutions such as merging or radical changes to the format could be discussed
  • some portals would be sufficiently improved that readers would benefit
  • if the portal did go on to MfD, it would be likely to have a smoother ride to deletion

Some obvious disadvantages:

  • it would take longer and it's not really suitable for batching, so it would slow down the reduction in number of portals
  • it's harder to see how scope/topic breadth could be brought into the critique, as that's difficult to improve in what's still a relatively short timescale
  • there isn't consensus on what "a truly miniscule article base" means in practice
  • those outside the project would no doubt continue to bring portals straight to MfD
  • admins closing MfD discussions would need to buy in to the keep argument that the portal should have been brought to the process first

Thoughts, anyone? Espresso Addict (talk) 17:49, 1 May 2019 (UTC)

First, thanks for the good thoughts on portal improvement, here, and of course elsewhere. Second, I think this is a solution to a problem that is pretty temporary: I think we have only a couple weeks more, at most, of significant MfD nominations. But I do think all would benefit if we can get back to running this WikiProject more like other projects, focused on collaborating around the quality (n.b.: not quantity!) of their content. Even without bringing back featured portals, there are things we could do. Other projects have article-improvement-of-the-month; let's have a portal-improvement-of-the-month for May: have the project nominate one portal that a large subset agrees should stay but that needs help, slap a {{construction}} tag on it, rope in the related subject-area WikiProject(s), and see what happens in a month. Other projects have missing article drives; let's have a single missing portal drive: have a process to nominate one missing broad-subject portal each month, create the shell, and again, rope in the related subject-area WikiProject(s) and build the high-quality portal. Thoughts welcome. UnitedStatesian (talk) 18:12, 1 May 2019 (UTC)
@UnitedStatesian: I fear that we all have such different ideas as to what constitutes an adequate portal, and how many portals is a good number, that we are going to be continuing to have a stream of deletion requests, hopefully at a reduced rate, for months, with escalating howls of anguish from maintainers who find their portal is next up. I don't know if we can resurrect portal peer review to review portals that the nominator did not create, especially when one possible outcome of drawing a portal to the attention of the community is a request for deletion.
These are all good ideas. I'm 100% behind trying to focus on quality not quantity. There's also some thinking harder to be done about what these automated methods can do to improve quality, rather than erode it. We've all spent a lot of time talking round in circles on this project, without doing an awful lot to improve the portals in our care. I think we should probably focus at present on what we have, rather than creating new – at least unless there are really obvious gaps that someone cares to bring up.
If you want to suggest a portal for collaboration, how about Portal:Companies? Very high hits (relatively speaking!), very limited content. Espresso Addict (talk) 20:02, 1 May 2019 (UTC)
@Espresso Addict: Funny you write that since I am proud member of Wikipedia:WikiProject Companies; you must have checked my contributions! I'm not ready to tackle Portal:Companies since it is not yet clear to me how/if it will interact with Portal:Business. How about Portal:Nautical? UnitedStatesian (talk) 17:11, 2 May 2019 (UTC)

Long reply and ALT proposal from BHG: the incubator

I really appreciate all the deep thought and good intent in Espresso Addict's proposal. Huge thanks, EA for the time and care you put into it.

Like @UnitedStatesian, I think that the current phase of MFDs is slowing down. We've mostly finished the automated spam, and are motoring fast through the set of long-term abandoned portals. I am not seeing a problem there.

But there is a problem with the much larger set of portals which are poor but not obviously-kill-it-now abysmal. So I think EA is asking the right question about what to do with them, even if that wasn't EA's primary focus.

However, I have two fundamental objections to EA's proposal as formulated:

  1. It puts a process barrier between editors and XFD. I am not aware of any other such barrier, and creating one would requite a broad community consensus at RFC. I would oppose such a barrier for three reasons:
    • As a matter of basic principle, XFD should be drectly accessible to all editors. It's kinda the ultimate safeguard against cliques: let everyone pile in.
    • Technically, MFD is easy to access because Twinkle will auto-build the nomination. That may sound trivial, but it's actually really important, because Twinkle makes MFD accessible in practice as well as in theory. (Without Twinkle, most editors find XFD about as accessible as a wheelchair user finds a wide-open door at the stop of a flight of steps). An alternative process would not be as accessible.
  2. EA's proposal puts this project in pivotal position, and bluntly I don't trust this project with such a role. I don't trust it to try to work within broad community consensus. There are some fine editors here such as EA and Bermicourt for whom I have huge respect, but too many others whose judgements seem to me to be a long way removed from the outcomes of broad community discussions ... and the project's record is not encouraging.

So, I'm sorry, but I object long and hard to EA's proposal as currently formulated.

However, my suggested alternative isn't a million miles away, but avoids the pitfalls above. It's simply this: create a pseudo-draft space for portals, with no link from reader-facing pages, i.e. not from articles, categories, navboxes, sidebars or other portals. Much like the existing "Draft:" namespace. Forget the "how" for now, just consider the way it could be used:

  • If desired, new portals could be moved straight to draft space (if they haven't already been created there), pending review
  • any internal project review process of existing portals could move them to draft
  • MFDs would have a third option, just as AFD does. Consider some of the recent MFDs where there has been an editor pledging to fix it all up after a decade of neglect, and in no time make a magical wonderful portals that everyone will love. I'm one of skeptics who and say delete; EA and others are more inclined to say let-em-try. Both views have merits, but if we had a draftify option then I think we could both agree to compromise on "take it offline and let the would-be maintainer develop it"

I think that would radically defuse a lot of the existing tensions. Those like me who want less reader-facing junk in portalspace would achieve what we want, while I hope that those of a more eventualist approach who hate seeing anything deleted would be satisfied too. I think this would take most of the heat out of MFD, because actual direct deletion would be the preferred option of those like me only when the scope was clearly too small. No need to toss a coin on the marginal cases; just draftify and see if anyone turns up to get stuck in.

I came here to start a new discussion because I had encountered some portals which I thought were too poor to leave as reader-facing pages, but which didn't seem to me to be clean deletes, e.g. Portal:New Orleans. See Special:PrefixIndex/Portal:New Orleans: lots of quite well-selected pictures, but pitiful article content. I don't think a picture-gallery should be a live portal, but OTOH if someone were to re-build the portal, it'd be a shame to have to rebuild that gallery.

So I thought up a way in which I think I can make draftify work for portals. And having read EA's proposal, I think it would allay a lot of EA's concerns. (EA, obviously please critique mine hard if you see any failings).

It's quite simple: don't use the "Draft:" namespace, just move it to a new name with a special prefix in front of it. My initial suggestion is "Incubator — ", I.e. Incubator — or Incubator &mdash; ... but obviously there are other possibilities. (Just not "Draft", to avoid confusion)

So take Portal:Jimbo Megacity, about the Jimbo Megacity meagalopolis in Wikitania. It has a population of 20 million, the world's highest GNP per capita and en.wp has copious coverage of its illustrious people and their stupendous achievements. GA-class head article, >800 non-stub articles within scope including lots more GAs and some FAs.

However, the current Portal:Jimbo Megacity is dire. Five rubbish photos, 1 selected biog (a stub on some minor lawyer of at best marginal notability), and a selected article about some minor bank robbery 15 years ago.

  • Eventualist insists: c'mon, it'll be easy for somebody to make this good! Don't just kill it! There's no deadline.
  • Deletionist replies: yeah, but when will it get good? There are 500 other crap portals, and this one has been rotting since we got the new steam-driven server in 1802[diff].

Both sides are right, just have different priorities.

So I reckon the win-win solution is: move it to Portal:Incubator — Jimbo Megacity, along with all its subpages, leaving no redirect. A one-click move, just like any other.

Hey presto! It's all intact. It will still work as before, and can still be developed with none of the glitches that arise in the "Draft:" namespace.

Can anyone see a downside to this? --BrownHairedGirl (talk) • (contribs) 02:27, 2 May 2019 (UTC)

@BrownHairedGirl: There has not been a better idea in the history of ideas for portal creations!!!
Suggestions:
(1) Call it Portal:Ω and make everything a subpage of that. Therefore, in your example the move would be to Portal:Ω/Jimbo Megacity and its section on topics to Portal:Ω/Jimbo Megacity/Topics. Portal:Ω is what I suggest because this way it alphabetizes/categorizes the portals to the bottom of any list (per WP:SORTKEY). I know it'd make things difficult to type out, but it can save us a lot of backend work where things like Special:PrefixIndex/Wikipedia:Miscellany_for_deletion/Portal: isn't cut in half by a huge list of pseudo-portals.
(2) We have the option of undeleting thus far deleted portals per WP:SNOW if a user in good standing pledges to maintain them (limited the amount of requests they could make of course). *cough*Portal:Webcomics*cough*
(3) This gets implemented as soon as feasible please. This would really save us a LOT of time. –MJL ‐Talk‐☖ 03:12, 2 May 2019 (UTC)
Thanks for that endorsement!
Sorry, @MJL, but I am pretty sure it can't have a slash in it. Some of the modules interpret slash in a special way, so adding one will cause malfunctions. And I think it probably should include plain English, for clarity. --BrownHairedGirl (talk) • (contribs) 03:23, 2 May 2019 (UTC)
Perhaps Portal:Ω Jimbo Megacity? I like the idea of having a non-latin character. Would [[Portal:& Omega Jimbo Megacity]] work? — Arthur Rubin (talk) 04:42, 2 May 2019 (UTC)
@Arthur Rubin, as afar as I know, only a slash would cause trouble with the Lua module, though I have not examined the code for other possible issues. But ampersand is best avoided, because it has a special meaning in URLs, and it I'm not sure what issues arise where from the need to encode it in titles.
If the consensus is do it and to use a non-latin character, then so long as there aren't technical issues, I'll go with that. But I think it would be a very big mistake to use some form of code which is non-obvious to the casual reader or the non-portal-specialist editor. Anyone looking at Portal:& Omega Jimbo Megacity will ask "zOMG! WTF?!?!?" and either waste time trying to find out, or move it to some non-WTF title, which would defeat the whole point of the exercise. The less explanation needed the better. --BrownHairedGirl (talk) • (contribs) 05:19, 2 May 2019 (UTC)
  • Comment. I fear the major reason that portal deletion requests have slowed this past week is that one of the major instigators is blocked. Otherwise they seem to be ongoing at a faster rate than I can readily keep up with. (I know this is a crowd-sourced project, but MfD does not usually attract many participants (unless the discussions are listed at CEN!)).
First off, I don't think BrownHairedGirl's and my proposals are incompatible. My process is explicitly optional. If implemented, some editors would continue to go straight for MfD; some closing admins would wholly discount "should have gone to the review process first" arguments. Because it would be optional, I don't personally think it would need a community-wide RfC to implement, though I note BHG's disagreement on this point. I don't know how pointful it would be, though, if those who wish to delete low-quality portals were not prepared to give it a whirl. In most implementations I wouldn't see the result as binding, either. If someone closed a review discussion as "sufficiently improved", the original nominator would be completely at liberty to say "no it ain't, -->MfD!!!".
What both BHG and I are proposing, I think, relates to what to do with portals that are (1) clearly substandard; but (2) have what I'd call "legs", ie are not obviously a waste of everyone's time. I don't want to link to specific MfD discussions here but at least some of the recent batch of mainly US university portals might be an example. My process would allow project members to find such portals and to try to rally others to work on them in the immediate short-term (month), without the overt threat of deletion hanging over everything.
Some first thoughts on BHG's idea, which I genuinely think might have legs (to use the above terminology):
I've never used either Twinkle or AWB (I edit entirely by hand, and always have) so I don't know how easy it is to make XfD deletion discussions for newbies. (Can new editors even get Twinkle/AWB??) In my experience, ~95% of XfDs come from a relatively small band of regulars, and XfDs brought even by good-faith newbies are usually speedy kept. What I would be suggesting would be slimline, informal, and hopefully relatively easy to do -- eg adding a comment to a page. If lots of portals were being considered in detail, we'd need to develop subpages, but the DYK nomination system seems to manage to get newbies to do that without too much hand-holding. If there was a moderator (and I'd offer to moderate if that were helpful), the newbie could comment on the top page, and the moderator could create the subpage for them.
Is it really trivial to move multi-page portals? How does that work exactly?
How would we deal with someone creating a new portal to fill the perceived hole?
As I've mentioned in a recent MfD, portals used to be categorised into "live" vs "under construction". The latter weren't linked from mainspace and did not appear in either the category or the list of portals. This seems to have got lost in the wash of moving to the new portal maintenance template. One of the consequences of that appears to have been that a number of portals that had long been abandoned in the under-construction state suddenly went live. I wonder if we could implement Incubator/"Draft" (I'd oppose the use of the omega character for a bunch of reasons) without needing to move portals at all, merely by putting a box at the top of the page that reads "This portal is under construction/redevelopment..." and moving mention of it out of all reader-facing places?
I've had some experience of draftification for new stub articles and basically once an article is draftified, it is very unlikely ever to get any further edits. It's removed from mainspace and all the tracking/content categories & project tagging that enable editors to find it, and usually lingers around until the six months is up and then is deleted G13. If this proposal were genuinely going to work as an incubator, rather than effectively deletion, then that would need to be addressed. (On a side note, Articles for Creation was, I thought, intended as an incubator process, to hand-hold newbies through developing a basic acceptable stub that isn't speediable. What actually exists is anything but – articles need to be super-notable & approaching C class to escape, IMO, and at least some of those who work there object vehemently to the notion that they should help the newbie to improve the article. I'd rather not duplicate that here.)
What I strongly object to – and for clarity, this is not at all what BHG is proposing, but I can see almost any system being used to negative ends – is any process that takes a large number of extant, hand-curated, non-broken portals based on some relatively arbitrary threshold (eg number of [textbox]subpages, number of non-stub articles in head category, date of last update, hit counts, date in the template, maintainer listed &c&c) and removes them to a limbo where they are unlikely ever to be worked on. To be honest, swift deletion would probably be more sensible. Espresso Addict (talk) 09:25, 2 May 2019 (UTC)
@Espresso Addict: It's removed from mainspace and all the tracking/content categories & project tagging that enable editors to find it This is why I suggested a non-latin character like Portal:Ω (which btw, Portal:Ω/Webcomics, Portal:Ω:Webcomics, or Portal:Ω Webcomics or whatevs makes no difference to me. I suggested subpages just because I figured the technical limitations were less of a problem, but I guess that wasn't true lol). Having a non-latin character means we can keep them in all the hidden/tracking categories without getting in the way of the regular portal-space portals. The alternative to that solution is Portal:Zzz-Incubator which is fine, I guess (just prone to miscapitalization).
A separate reason I preferred Portal:Ω is because it isn't supposed to reader-facing anymore once it is moved to that title. –MJL ‐Talk‐☖ 16:40, 2 May 2019 (UTC)
I have no idea whatsoever how to move pages to a title including any non-Latin character reliably. Outside Wikipedia I've worked on database-driven websites where one of the major problems was titles with en rules in them; they sort differently according to where exactly one sourced the en rule from,and they display differently on different browsers. Espresso Addict (talk) 16:51, 2 May 2019 (UTC)
@Espresso Addict, I am going to create a silly sample portal to play with and test this idea. {{subst:Box portal skeleton}} here I come! --BrownHairedGirl (talk) • (contribs)
@BrownHairedGirl:Good luck – be warned this portal creation process is addictive :) I don't see in principle why we can't use all of your incubator, my idea of a negative side to peer review that leans towards deletion, and a portals for creation process to filter this stuff before someone goes to the bother of creating it. Espresso Addict (talk) 21:23, 2 May 2019 (UTC)

Portal:Shia Islam

Latest comment: 4 years ago4 comments2 people in discussion

Would anyone please resolve the problem in the 'Chosen holy figures' box? Husayn ibn Ali is not shown correctly in the box. Regards. --Mhhossein talk 09:27, 21 April 2019 (UTC)

Hey The Transhumanist. Can you give it a try please? --Mhhossein talk 13:17, 26 April 2019 (UTC)
I've fixed it.--Auric talk 01:10, 27 April 2019 (UTC)
Auric: Thanks so much. --Mhhossein talk 06:23, 3 May 2019 (UTC)

Redirected portals

Latest comment: 4 years ago36 comments8 people in discussion

Portal: namespace has many redirects for good reasons. However, a few portals were discussed at MfD, found no consensus or a consensus to keep, but were subsequently replaced by a redirect to a broader portal. As this may have been accidental, I would like to respect the MfD outcomes by restoring these portals. The topics are narrow and the portals could be improved, so I see no objection to their immediately going to another (possibly bundled) MfD.

Any objections? Certes (talk) 19:00, 29 April 2019 (UTC)

I have no objection even though I am one of the 3 redirectors. UnitedStatesian (talk) 19:01, 29 April 2019 (UTC)
No objection to restoration. North America1000 19:10, 29 April 2019 (UTC)
I strongly object to restoring Portal:Years. The last version[1] before redirection[2] by @Fram was just an empty shell, similar to mountains of similar junk which we have deleted in recent weeks. If it's restored, I will immediately MFD it, but please @Certes will you spare us that discussion?
The Feb 2017 MFD was all about "potential", but we have far too many of these abandoned portals with "potential" which never be realised because there simply aren't enough editors interested in maintaining them. That MFD included a boast of the staggering popularity which meant it actually received 286 page views in the last thirty days. That's just under 10 views per day, which is abysmal.
It's also a spectacularly pointless portal, for reasons I hope should be obvious, but just in case anyone misses it: I don't need a pseudo-portal to serve a random year, cos I can just type in a random number <=2019 in the search box and go directly to an article.
Some redirects may be worth restoring, but that one?
Similarly, Portal:Quidditch. For goodness sake, it's a fictional sport from one novel series. That's a classic example of a narrow topic. --BrownHairedGirl (talk) • (contribs) 19:22, 29 April 2019 (UTC)
Fair enough: I'll abandon the idea. I agree that quidditch is too narrow a topic to justify a portal. I just felt that being seen to respect the community's views as expressed in two MfDs might show this project in a better light than effectively deleting the page in the face of repeated consensus not to do so. Certes (talk) 19:28, 29 April 2019 (UTC)
@Certes: Two discussions, both poorly attended. Consenus can change, in respect of portals there clearly has been a big shift in the last 10 weeks.
If this project wants to recover from its well-deserved leper-status, unredirecting a narrow-scope portal on a niche topic is not the way to go. --BrownHairedGirl (talk) • (contribs) 19:43, 29 April 2019 (UTC)
  • Comment. I wouldn't bundle these three together as they seem rather different.
  • Quidditch is a classic example of a narrow topic not suitable for a portal. The 2nd MfD (2018) closed with keep but the closer noted "Discussions about upmerging to the Harry Potter portal can be done on the talk page", so redirection is clearly possible if such a discussion was held, and possibly even if it was just done and no one objected.
  • Kent might be suitable for a portal, depending on how much coverage the encyclopedia has, but was MfD'd back in 2013 as no consensus and remained a sea of redlinks until Transhumanist et al. started working on it last year.
  • Years is covered above, and on a brief look I agree with BrownHairedGirl's assessment. Perhaps Portal:History could link to those of the individual decade portals that are worth promoting, which it does not seem to at the moment? Espresso Addict (talk) 05:08, 30 April 2019 (UTC)
  • There's a lot of coverage of Kent, so if we are merely counting the number of available non-stub articles, it's a clear yes. However, I am less persuaded that a 3rd-level national subdivision is conceptually a broad enough topic for a portal, given the low interest from both readers and maintainers. Two weeks ago I began drafting a batched MFD of English county portals, but decided not to pursue it for now because I think it's probably more of an issue for wider discussions about suitable topics for portals. But my sandbox draft shows a severe lack of reader interest in the existing county portals. --BrownHairedGirl (talk) • (contribs) 12:43, 30 April 2019 (UTC)
  • @BrownHairedGirl: I guess you realise that you are not going to win me as a friend by suggesting deleting English county portals. I don't think, given the clear bias towards English-language topics here and the long history of some of them, that they are not broad enough – but then I wouldn't, as I've spent years of my life working on one. I will say that the portals are very far from all being the same; some were backed by very active Wikiprojects, others never had a functional project. Espresso Addict (talk) 13:19, 30 April 2019 (UTC)
  • @Espresso Addict, I have no desire to alienate anyone, but I also won't shy away from pointing out facts just because some editors find them uncomfortable.
English counties are only Level-5 Vital Articles. It's clear that readers don't want these portals. So at some point we need that wider discussion about how much to retain the vast numbers of unread portals on low-priority topics. But as noted above, I think that discussion needs to start somewhere other than MFD, and probably requires prior broad discussion of the higher-level principles around portals. --BrownHairedGirl (talk) • (contribs) 14:37, 30 April 2019 (UTC)
With respect, we keep quoting Wikipedia Vital Article levels, but frankly that system is just unbalanced as the portal system and not AFAIK part of the criteria for portal guidelines. And counties are only level 5 because England has been inserted below United Kingdom, so English counties are automatically one level below than e.g. oblasts in the Ukraine or tiny cantons in Switzerland. The concept is good and I could see us using it intelligently in future to assess portal relevance, but in its present state it's not a pretty poor guide. Bermicourt (talk) 15:42, 30 April 2019 (UTC)
Sure, @Bermicourt, VA is flawed, but at least it's an actual attempt to define some sort of hierarchy of priorities, whereas portals have mostly been created just on an I-feel-like-making-this basis. I don't take VA as anything approaching gospel, but it's a good initial guide.
As to the the UK, it does have 4 primary divisions: England, Scotland, Wales and Norniron. England is then subdivided into regions, with counties below that, and the average population of a non-metropolitan county is ~500,000, so they aren't big units.
The question I have in the back of my mind all the time is "how many portals can be be sustained overall?" ... and if the set of portals is going to be anything other than haphazard, I don't see much chance of sustaining a set which extends down to such small units unless portals are radially simplified. (Back to the excellent example of Portal:Harz Mountains again!) --BrownHairedGirl (talk) • (contribs) 16:58, 30 April 2019 (UTC)
I respectfully disagree, BrownHairedGirl. By far the best way of getting maintenance work is to allow people to create & work on the portal topics they are passionate about. If my portals were deleted, I would not take up working on some other assigned Big Important Topic Portal. And there's no reason why we should attempt portals for all x where our coverage can differ radically. Espresso Addict (talk) 18:18, 30 April 2019 (UTC)
ETA: @BrownHairedGirl: the average population of a non-metropolitan county is ~500,000, so they aren't big units. Which average is this, by the way? If you look at the 2017 estimated population figures then only five "real" (ie excluding the tiny outliers of Isle of Wight, Rutland & City of London) counties have a population of less than 500k. Espresso Addict (talk) 06:14, 1 May 2019 (UTC)
I've just shoved the table into Excel, and the average population of all counties is mean 1.2 million, median 906k, which changes to mean 974k, median 902k if one excludes the three urban ones at the top (Greater London, West Midlands & Greater Manchester) and the three outliers previously mentioned from the bottom. Espresso Addict (talk) 06:52, 1 May 2019 (UTC)
BrownHairedGirl I agree that portals need sustainability, although well designed / mature ones need little maintenance, so that should be a factor in what is acceptable. Re populations, just look at some of the Swiss cantons - I think I saw one with a population of c. 30,000! So again, it's a factor not to be scorned, but not to be the sole criterion. But I think you and I could agree on a lot of that, at least in principle, if not on the actual levels in every case. BTW I'm glad that Portal:Crawley got deleted; that never merited a portal, especially a half-finished one. Bermicourt (talk) 18:51, 30 April 2019 (UTC)
@Espresso Addict, there are several problem with niche portals, e.g.
  • they rely on the continued attentions of the one editor whose passions drove the creation. When that editor stops, it's less likely that someone else will fill the gap
  • they set a precedent for the creation of other niche portals by less experienced and/or committed editors. (see e.g. [3])
  • they are more likely to draw on less closely-monitored content
@Bermicourt, yes it is possible to design portals which don't need much maintenance, and you have created some good examples thereof. But once you get into the dozens of sub-pages with content forked from the main article, you're in high-maintenance territory.
I agree that any rigid formula will lead to absurd creations as well as absurd omissions. But AFAICS, there needs to be some combination of:
  1. importance of topic
  2. breadth of topic
  3. quality of article set
  4. some cluster of editors who will at least monitor it, and preferably maintain it
  5. some review or pre-approval mechanism with a checklist to assess whether it genuinely offers value beyond that of other pages pages on the topic.
--BrownHairedGirl (talk) • (contribs) 21:07, 30 April 2019 (UTC)
  • User:Bermicourt, do you have any evidence to support your statement above that "counties are only level 5 because England has been inserted below United Kingdom, so English counties are automatically one level below"?  Geographic areas are not always assessed as being (at least) one VA level below the area that they are part of - e.g. (perhaps taking an extreme case) Paris (VA3) is part of Île-de-France (VA5). If your statement is just an (incorrect) assumption please strike it. DexDor (talk) 19:04, 30 April 2019 (UTC)
  • @Espresso Addict: to your statement above that you would "not take up working on some other assigned Big Important Topic Portal": not sure what the county closest to your heart is, but say that instead of being located at Portal:Favourite County and subpages, as is presently the case, all of the portal content was at Portal:United Kingdom/English Counties/Favourite County and subpages? Is there really a difference, in your view? Just trying to find some win-win middle ground here. UnitedStatesian (talk) 23:12, 30 April 2019 (UTC)
Er, yes, there really is a difference. I can't imagine how one would subsume a fully developed county portal into Portal:United Kingdom – which btw is on the list of those trashed, I notice – or why on earth one would want to. Espresso Addict (talk) 23:31, 30 April 2019 (UTC)
I'm not saying the current version of Portal:United Kingdom, but imagine a true, very broad country portal for the UK. Look at Portal:Human body: each other tab across the top leads to what is effectively a separate portal, except . . . each isn't: each was made up of (and will be again, once my WP:REFUND requests are complete) subpages of Portal:Human body, so: doesn't count in how many portals exist, not subject to discussion of "is it a broad enough subject?", doesn't have its pageviews counted, unlikely ever to be separately brought to MfD, etc. You see where I'm going here? UnitedStatesian (talk) 00:12, 1 May 2019 (UTC)
@UnitedStatesian: That's an interesting model of a portal, or it was before someone deleted it all! If there's no other solution to sub-regions that kind of fadge might be an avenue to explore. If one wanted to retain the portal colours, then the frame portal would probably have to be white, not a distinctive colour scheme such as pink/orange. Also what would you do with 48 tabs? If you were not careful you'd just reduce the hits by making the existence of a subportal less obvious.
Would you, by the way, also be suggesting doing that for US states? Seven of which have lower populations than the County of my Heart?
I'm not really seeing how it benefits the project though, other than reducing #PORTALS, as it would require just as many subpages. Espresso Addict (talk) 06:06, 1 May 2019 (UTC)
Yes, I would suggest doing it for all subnational divisions other than cities: U.S. states, German states, all of them. And I think reducing #PORTALS (to several hundred or so) is a huge benefit to the project: makes WP:ENDPORT2 less likely, significantly drives up per-portal pageviews, increases editor collaboration, etc. Number of subpages dedicated to high-quality portals does not matter at all. UnitedStatesian (talk) 14:29, 1 May 2019 (UTC)
Noted. If it was agreed to put all sub-national portals in a structure so that they were technically within the national portal, in such a way that all the portal's features (including colour scheme) could be accommodated, that might be less offensive. I worry it would still further reduce these portals' hits, though. And I don't know how much traction you'd get from US editors for the suggestion when it related to US states. Espresso Addict (talk) 15:16, 1 May 2019 (UTC)
  • I object to a sweep of reverts to redirected portal. Over many years, before this year, the vast majority of MfD-ed Portals should have simply been redirected, they were over-specific and completely redundant to another Portal. In some cases, this can be done recursively three times over. Reverting a redirect to make live again a redundant Portal is not an improvement and so don't do it. --SmokeyJoe (talk) 03:36, 1 May 2019 (UTC)
UnitedStatesian, if you really have to unredirect junk like those two pages, please will you at least MFD it yourself, rather than leaving others to find it and nominate it? --BrownHairedGirl (talk) • (contribs) 13:08, 1 May 2019 (UTC)
Of course, @BrownHairedGirl:, that was always my plan, as you will see from upcoming noms.; apologize that I got pulled away unexpectedly and was not able to complete the MfDs before you got to them. I do think there is some value to un-redirection followed by MfD discussion, as, for example, we currently we have all the subpages for Portal:Quidditch and others hanging out in limbo. UnitedStatesian (talk) 13:17, 1 May 2019 (UTC)
I think that is even more stupid than ignoring portals. Do you enjoy busywork? Or do you enjoy putting others to busywork? The point has been made with MfDing portals. What more do you hope to achieve at mfd? —SmokeyJoe (talk) 13:26, 1 May 2019 (UTC)
  • All redirected portals should stay redirected until they become eligible for WP:CSD#G8, when the target gets deleted. Portal subpages can be redirected to their main portal page. A dispute about a redirection of a portal, cases of Wikipedia:Pseudo-deletion by redirection, can be formally discussed at WP:MfD and reviewed at WP:DRV, but only if there are at least two people in disagreement. --SmokeyJoe (talk) 01:46, 3 May 2019 (UTC)
I hope those fears are unfounded. I'm assuming good faith, rather than seeing the redirects as preparation for stealthy deletion via G8. Certes (talk) 02:10, 3 May 2019 (UTC)
Ill considered portals, ill-considered because they are too thin and completely redundant to another portal, should be redirected to the portal that covers the topic. There is no deletion concerns with that.
If, later, the community decides to delete portals wholesale, that will be the deletion decision that covers the history of the redirected ill-considered portals. I don't see anything much to worry about. A community decision to delete many, most, or all portals will not be stealthy. Ill considered portal histories behind redirects will not be missed because G8 bots will sweep them up. There is no need to revert their redirection to get them deleted.
My preference is to archive all of Portalspace, not delete it, there is no history in it that needs hiding. For anyone particularly enthused to continue with Portals, let them fork it offsite, anytime they want. I think portals have not been fo rthe benfit of the prject for at least 15 years, if ever. I think there is only one portal that needs keeping, Main Page, and it is in mainspace. Something needs to be done with the confusing Wikipedia:Community portal. --SmokeyJoe (talk) 06:56, 3 May 2019 (UTC)
To be brutally honest, SmokeyJoe (and I realise you were pointed here from an MfD by, I think, BrownHairedGirl), I don't think repeating these views here is pointful. You're entitled to hold them, and this project is of course bound by well-conducted site-wide RfCs, but in the meantime it only inflames matters to rehearse them in front of those who are bound to disagree vehemently with you. Espresso Addict (talk) 10:40, 3 May 2019 (UTC)
(ec) @SmokeyJoe, you make my heart sink.
WP:ENDPORTALS was a year ago. It closed as don't delete all portals. It's fine for you to wish it was otherwise, and hope to overturn it ... but unless and until that is overturned at a new RFC, that's established WP:consensus. And we all have to work within that consensus.
So proposing options now on the basis that everything is going to be deleted anyway is a WP:IDHT approach, and musings about overturning the consensus are disruptive to a discussion on the immediate issues which are undecided. --BrownHairedGirl (talk) • (contribs) 10:47, 3 May 2019 (UTC)
I think I am being misunderstood. There is no decision to delete all portals. Unless that decision is made, an unlikely hypothetical, redirected portals will not be deleted. Redirected portals are not being backdoor deleted. —SmokeyJoe (talk) 10:57, 3 May 2019 (UTC). Portals that are too thin should be redirected, not MfD-ed. Deletion is for things that should have never been. —SmokeyJoe (talk) 10:59, 3 May 2019 (UTC)
@SmokeyJoe, redirected portals will be bot-deleted per G8 if their target is deleted. So it's better to have a discussion, because otherwise redirection becomes a path to stealthy deletion.
And in the case that led us here, we were dealing with what was basically an abandoned test page. There's no need to get finnicky about preserving that for posterity. --BrownHairedGirl (talk) • (contribs) 11:05, 3 May 2019 (UTC)
I am not emotionally involved with any of this, and I seemed to have been sidetracked, with different thoughts crossing. I thought I was here from talking about Portal:Narendra Modi. If that is redirected to Portal:India, it is not deleted. I think that would be a good outcome, because Modi belongs in Portal:India. I am indifferent to whether Portal:India continues. —SmokeyJoe (talk) 11:12, 3 May 2019 (UTC)

Reverting portals to the manual version

Latest comment: 4 years ago9 comments4 people in discussion

I've done this a couple of times eg Portal:Amusement parks, but the format seems to come out one column, which is not what's intended. Can anyone tell me what I've done wrong? My manual two-column portals, which never got converted, have not shown any signs of morphing into one column behind my back. Espresso Addict (talk) 11:25, 3 May 2019 (UTC)

I've just been reverting them to a state prior to conversion, but drew both positive and negative responses for doing so. In the case of this portal, the version prior to any edits by TTH is actually the one column version. Here's a version of this portal prior to conversion that has the two column approach. Looking at the code it appears there is a float left and float right parameter in the fourth and eighth paragraphs respectively. One could simply copy the code area and try it out. That's how I learned this stuff. BusterD (talk) 13:33, 3 May 2019 (UTC)
Thanks, BusterD. I'll see if I can fix it by using the column code that my working two-column portals use. I pootle around with css in my personal websites, but I don't want to screw things up in mobile view, of which I am supremely ignorant. Espresso Addict (talk) 13:55, 3 May 2019 (UTC)
¯\_(ツ)_/¯ –MJL ‐Talk‐☖ 13:47, 3 May 2019 (UTC)
  • Well, I've tried everything I can think of, and it's resolutely single column. I've posted a note on John of Reading's talk page, as it was his bot that did the conversions to the mobile-compatible columns, to see if he can help. Espresso Addict (talk) 14:34, 3 May 2019 (UTC)
The style definitions needed by the bot edit have been moved from global CSS into Template:Portal styles, so any portal that tries to use them nowadays needs to transclude that template. -- John of Reading (talk) 14:50, 3 May 2019 (UTC)
(More) I see that most portals pick up that template via Template:Portal maintenance status. -- John of Reading (talk) 15:01, 3 May 2019 (UTC)
That's very useful. Thanks! BusterD (talk) 15:02, 3 May 2019 (UTC)
Thanks, John of Reading! If all else fails, ask someone who knows what they are talking about :) Espresso Addict (talk) 15:23, 3 May 2019 (UTC)

For what it is worth . . .

Latest comment: 4 years ago11 comments5 people in discussion

I found it interesting that despite some talk of a "war on portals," at this writing all of the recent MfDs have not yet led to a single deletion of a portal that was a Wikipedia:Featured Portal while that process was running. Not one. A few are at MfD currently, and I am sure this perfect record will not stand forever, but the community does not yet show any appetite to delete, let alone massdelete, portal content that was once formally recognized as being of high quality. UnitedStatesian (talk) 16:52, 2 May 2019 (UTC)

Which are up at present, do you know? I thought they'd nearly all closed as keep. Portal:Halo is the only one I can think of at present. Espresso Addict (talk) 16:58, 2 May 2019 (UTC)
Off the top of my head, the 3 state roads portals are up too; that MfD is looking like a keep also. Expect an MfD that includes the 2 small cities too. UnitedStatesian (talk) 17:07, 2 May 2019 (UTC)
"War on portals" is just alarmist, scare-mongering propaganda by a few editors who have chosen not to look at what's actually happening, and prefer to allege bad faith than to stop and watch.
The wave of deletions has been been firstly about removing the portalspam, and secondly about deferred housekeeping: removing portals of v low quality and/or excessively narrow topics. The MFDing of portals which have were still-born a decade ago should not be needed. It is happening now only because a) it was a not done much sooner, and b) outsiders have started peering inside the cupboards where the project chose not to look. --BrownHairedGirl (talk) • (contribs) 17:08, 2 May 2019 (UTC)
Oh, I'd forgotten those. Thanks, UnitedStatesian. They have very active projects backing them, as I recall. It was I think Legacypac who nominated Portal:Architecture, which was one that really made me cross. Espresso Addict (talk) 17:14, 2 May 2019 (UTC)
Me too: I !voted keep on that one without any hesitation. Though to his credit he did more good work than bad when he was able to keep his temper in check. UnitedStatesian (talk) 17:17, 2 May 2019 (UTC)
Indeed. The problem was not just the temper, but the failure to recognise and repair screw-ups. So while he was right most of the time, the times he wasn't became a huge timesink. --BrownHairedGirl (talk) • (contribs) 17:30, 2 May 2019 (UTC)
I think that passing featured portals is an indication that there is a level of formal review done to assess the depth and breadth of the portal. So I am not surprised that none of the featured portals were deleted. OhanaUnitedTalk page 01:03, 4 May 2019 (UTC)
It's only a matter of time. There are new ones nominated every few days. Espresso Addict (talk) 01:58, 5 May 2019 (UTC)
@UnitedStatesian: I hope you know that you personally just nominated a former featured portal lol –MJL ‐Talk‐☖ 02:22, 5 May 2019 (UTC)
Yes. I did write "I am sure this perfect record will not stand forever", after all. And 170 out of 171 is still a pretty good record. UnitedStatesian (talk)
@UnitedStatesian: I'm more in accord with BrownHairedGirl's strategy of starting from the worst. Every former featured portal has had a peer review by a handful of portal experts and met some broad thresholds of content inclusion. This clearly differentiates them from the majority of the portals that did not go through the process. Espresso Addict (talk) 11:49, 5 May 2019 (UTC)

Portal maintenance status notes field

Latest comment: 4 years ago7 comments4 people in discussion

I was using this to record the actual maintenance status in the notes field, as a handy summary onwiki of the spreadsheets on my hard-drive. The visible talkpage note seems to have disappeared since I last looked. (It's still there in the portal code.) I don't see an edit in the portal maintenance template history that would make the notes field disappear. Can anyone elucidate? And if that's not an allowable use of the field, can I request a field for which it is allowable, because it was, as I wrote, handy. Espresso Addict (talk) 10:54, 2 May 2019 (UTC)

What template are you referring to, @Espresso Addict? --BrownHairedGirl (talk) • (contribs) 13:56, 4 May 2019 (UTC)
@BrownHairedGirl: Template:Portal maintenance status. Espresso Addict (talk) 14:24, 4 May 2019 (UTC)

Sorry, I couldn't quite figure it out in a quick check of the template and Module:Portal maintenance status.

However, the maintainer seems to have been @Evad37. Maybe they can help. --BrownHairedGirl (talk) • (contribs) 16:13, 4 May 2019 (UTC)

The code for showing Portal maintenance status on the talkpage is in Template:WikiProject Portals, which has recently been edited by MJL - Evad37 [talk] 02:21, 5 May 2019 (UTC)
@Evad:   Reverted I should have tested the changes I made more. My apologies :( –MJL ‐Talk‐☖ 02:34, 5 May 2019 (UTC)
Thanks, Evad37, seems to be working ok now. Espresso Addict (talk) 20:28, 5 May 2019 (UTC)

Project newsletter

Latest comment: 4 years ago9 comments6 people in discussion

I was going to propose we wrote one, given the large number of issues that would merit wider discussion, but I see The Transhumanist has done so. As that editor has not been participating in recent MfDs (as far as I can tell) nor in any of the ongoing discussions on this talkpage (also afaik), this is ... not the newsletter I might have co-written. ETA: As the newsltter repeatedly links the sub-talkpage, I have put a note there indicating that there are ongoing discussions here. Espresso Addict (talk) 11:04, 2 May 2019 (UTC)

For now, I think anyone interested in the progress of portals will get more timely updates by watchlisting relevant pages. There's a case for a newsletter to promote portals to editors who don't actively follow them, but this month's message of "Yay! We deleted another thousand!" is unlikely to boost recruitment. Certes (talk) 11:15, 2 May 2019 (UTC)
It had become a battleground and mudslinging fest. Not the collaborative atmosphere that the previous portal project participants had become accustomed to. Now that the dust has mostly settled, perhaps we can recapture that team spirit, and attract the members back. ;)    — The Transhumanist   11:57, 2 May 2019 (UTC)
The Transhumanist, that would be lovely, although there's still plenty of mudslinging going on I'm afraid. But there's plenty of work to do so hopefully we can get back to that collaborative atmosphere now and start making progress again. Other than the newsletter, I think we should work on:
  • Some definitive creation/deletion criteria for portals, based on the scope of the topic they cover
  • Some clarifications at WP:POG so it's clear which bits are best practice and which bits are minimum criteria for a portal to exist, and an update to reflect the lower maintenance overhead of transclusion based portals
  • A bit of a spruce up of the project talk pages - at the moment they're full of angst-ridden rants and it's hard to find useful, constructive discussions to contribute to or take notice of.WaggersTALK 12:22, 2 May 2019 (UTC)

Given the enormous shitstorm created by @The Transhumanist's spectacularly destructive portalspamming antics over the past year, his current topic ban and his failure to assist in the cleanup ... it seems to me to be an utterly outrageous act for TTH to issue a purported newsletter in the name of the project, esp since it appears to have been done unilaterally.

I am appalled. This is precisely the sort of Napoleonic, anti-consensus antics which led to the massive shitstorm in the last few months. Have you absolutely no shame at all, man?

In recent weeks, this project has been starting to have some good, fundamental discussions. TTH has chosen to take no part in those, but instead makes unilateral pronouncements in the name of everyone else.

If this project is going to allow TTH to Waltz back in and resume speaking for it without any consensus-building, then it's time to reopen discussion on shutting down the project and/or making TTH's topic-ban complete and permanent. --BrownHairedGirl (talk) • (contribs) 15:31, 2 May 2019 (UTC)

@Espresso Addict: I'm sure The Transhumanist could use some help with newsletter building (as far as I know The Transhumanist has always put together the newsletter solo, and it looks like a lot of work). While I found the last one informative and remarkably measured (and have said so "on the record"[4]), there's a whole lot going on that it doesn't get into, as you (Espresso Addict) touch upon.

While I've only participated in this project as an MoS advisor and an occasional commenter on open questions (and first arrived here as a skeptic, half-convinced that portals should just go away, only to have my mind changed by this renewed project), I think the witch-hunt against the project and its work, and especially the WP:BATTLEGROUNDing incivility against project participants as a class, cannot be permitted to continue. I attempted to get ArbCom (at a WP:RFARB opened by @Robert McClenon:, as I recall) to accept a case about this "portalwar" and the WP:ASPERSIONS, WP:AGF, WP:NPA, and related problems, as well as WP:TE and WP:POINT antics, about a month ago, and they declined. The situation has eroded sufficiently – despite the warning of being RfArb'd, and one of the instigators getting indeffed for directly related reasons, after the instigators turned on each other – that I think ArbCom would accept another case request. But I don't really consider myself a directly aggrieved party, just a shocked observer. Someone clearly needs a topic ban, but someone else from this project with a more direct grievance and better-collected evidence may have to ask for it.
 — SMcCandlish ☏ ¢ 😼  07:03, 5 May 2019 (UTC)

@SMcCandlish: I was going to propose at least 3 editors representing different sides of this discussion co-wrote a newsletter; perhaps next issue. I disagree as to exactly how measured the last issue reads; but I might be misreading its tone. I'm still not a card-carrying member of the project.
I don't work as an admin in conduct issues. I've personally managed to rub along reasonably well with multiple editors disciplined for incivility/misogyny in the past (I'm not referring to recent events), despite being female, and don't feel that Arbcom involvement generally improves matters. Espresso Addict (talk) 15:17, 5 May 2019 (UTC)
Generally Arbcom involvement can make things worse or at least cut both ways, but there are exceptions, and there necessarily are when all else has failed; it's a last resort for a reason, in both senses. Anyway, something like an editorial committee for the newsletter is a good idea, and seems to be how most wikiprojects with newsletters go about it. As for measured, if you read through all the "hate mail" across wikipedia directed at last issue's (and heretofore every issues's, I think) author, and all that's been done to eliminate as many portals as possible, and to go after that person in particular, and to malign the wikiproject en masse, I think what he wrote is remarkably calm, informative, concession-filled, forward-looking, and option-exploring.  — SMcCandlish ☏ ¢ 😼  19:57, 5 May 2019 (UTC)
I still don't think that an arbcom case would help anything, and would be esp unhelpful to an editor who claims that all that's been done to eliminate as many portals as possible. And the complaints about TTH's conduct have been extraordinarily mild all compared to the massive damage which TTH has done.
But the problem with this newsletter was not just its lack of any regret for the massive disruption caused by the spam. It was the attempt to speak with a single voice on behalf a group with which he had little involvement in the last few months, and to present a monolithic view. A newsletter now should have been noting the unresolved areas, instead of devoting so much space to TTH's own personal ideas about the future.
That tendency to speak ex cathedra and una duce una voce on behalf of the group is what led to so much being done last year without a broad consensus behind it. --BrownHairedGirl (talk) • (contribs) 00:11, 7 May 2019 (UTC)

Purpose of portals?

Latest comment: 4 years ago21 comments9 people in discussion

The portal purge has pretty much established, by limiting subject scope, that portals will not be allowed to become a comprehensive navigation system. (So, if you are studying oranges, you will need to go elsewhere, as the most specific relevant portal is on plants).

The reason for that is actually strategically sound, and goes something like this: most (if not all) portals get dismal traffic compared to the corresponding articles, and the lack of traffic is especially pronounced for narrow subjects. Therefore, the effort spent on them would be better applied to articles.

This doesn't make much sense until you consider articles as navigation pages, with the potential to be developed further as such. Far more people see the navigation features on root articles than those who look at all other types of navigation pages combined.

Not to take advantage of this fact is to ignore the profound benefit provided to Wikipedia by Google and other search engines. They bring the traffic to the doorstep of each subject: to its root article. That's what users type in as their search terms, and those are the pages they arrive at.

So, attempting to build a comprehensive navigation system in the portal namespace, which gets a tiny fraction of traffic by comparison, is misguided effort.

However, developing new or enhanced navigation features on articles directly could lead to another debacle like the infobox war, or the portal purge and reversion we just went through.

A better option might be to not touch the articles at all (that is, take an indirect approach), and develop the navigation elements as software features. Pop-ups are a prime example, as is the slideshow feature of Mediawiki.

This can be done through Phabricator (working with the developers of Mediawiki), or by developing userscripts/gadgets. The latter is probably easier than the former, and more hands-on accessible to editors.

As userscripts, new features would unlikely be the focus of deletion efforts, because all they would be changing is the view (not the saved articles themselves), and because their use would be optional. Only users who wanted to apply them would install them. If a userscript became popular enough, it may inspire the development of a Mediawiki feature.

Lesson learned: if you want comprehensive, to make it worthwhile: think "traffic".

Where does that leave portals?

As samplers (providing "topic tasters") for broad subject areas. Each similar to a Readers' Digest on a particular (wide) topic.

So, the community needs to decide how broad they want portals to be, and what any other selection criteria should be. And the place for such discussions is the portal guidelines discussion page (WT:POG). See you there.    — The Transhumanist   11:57, 2 May 2019 (UTC)

TTH, the place for such discussions is in broad RFCs at the village pump. Your practice of having project-space discussions with your cronies while shouting down objectors and not seeking broad community support, so that you could then stealthily rewrite guidelines according to your own personal preferences, is precisely what led to the almighty shitstorm which began in February.
If you are going to try to resume the destructive practices of before, then it's back to the drama boards time. --BrownHairedGirl (talk) • (contribs) 15:36, 2 May 2019 (UTC)
I disagree. Wikipedia talk:WikiProject Portals is the best place to talk about the Portals project. Also, please refrain from the use of profanity in discussions as it does not add any value.--Paul McDonald (talk) 15:57, 2 May 2019 (UTC)
@Paul McDonald, the practice of making broad decisions among a small clique in a sub-page of projectspace is precisely what led to the project getting so wildly out of step with community consensus that whole thing exploded as a storm on the drama boards, and led to the deletion in recent weeks of 75% of all portals. Big decisions belong at WP:RFC, and if that principle is any way controversial amongst fans of the portalspammer, then it's time for community intervention via the drama boards.
If you really, seriously, have any lingering doubt that there was something very radically wrong with a project which saw 75% of its pages deleted in two months, including 45% of them deleted by overwhelming consensus in in a pair of record-breaking WP:CENT-advertised mass nominations, then the community needs to intervene now before the cycle is re-started.
And, no I will not refrain from calling it a shitstorm. That's actually a severe understatement for a long-term project failure which exploded over WP:AN, WP:ANI, WP:VPP, WP:RFAR and WP:MFD. If you actually want to be constructive, stop trying to be a language cop and start upholding the core en.wp principle of WP:CONSENSUS-building. --BrownHairedGirl (talk) • (contribs) 16:44, 2 May 2019 (UTC)
Then why even have a page for Wikipedia talk:WikiProject Portals? If it's not for discussing the project, what would it be for? As for the other issues, I'm not opposed to the deletion of the recent large volume of portal creation. I am opposed to uncivil language.--Paul McDonald (talk) 19:14, 2 May 2019 (UTC)
@Paul McDonald, This is not complicated. Project space should be for discussing how to implement the community's consensus, or for identifying areas where consensus is unclear ... not for making big decisions without community support, and certainly not for steamrollering through huge changes to a whole namespace which were known from the outset to both controversial and unresolved.
Like Arbcom, I am massively less concerned about the profanity checks than about uncivil conduct. Steamrollering through huge changes, creating a huge storm, leaving others to clear it the mess, then wandering back and without any apology or regret, arrogantly presuming to speak for a whole bunch people and proposing to restart the conduct which led to the crisis in the first place .... that's a squillion times more uncivil than a whole pageful of plain words. --BrownHairedGirl (talk) • (contribs) 19:28, 2 May 2019 (UTC)
I'm with BHG on this one: TTH certainly has a lot of balls (is that profanity?) to waltz (Her word. Perfect.) back in after doing nothing to help with the cleanup (which is ongoing and will be for some time) and suggest proceeding without broad community consensus that is not possible to achieve in a WikiProject discussion. UnitedStatesian (talk) 20:09, 2 May 2019 (UTC)
Let's presume that is 100% correct at this point: that still is not a reason for uncivil behavior. See the essay Wikipedia:All Five Pillars are the same height and also A weak personal attack is still wrong. As is said above, the editor's actions indeed may be "a squillion times more uncivil than a whole pageful of plain words" -- simply being less severe doesn't bring the bad behavior into the category of good behavior. Nor should uncivil behavior be returned with more uncivil behavior. We have five pillars. They all matter.--Paul McDonald (talk) 21:08, 2 May 2019 (UTC)
Sadly, Paul, the only aspect of them that I have seen you expressing any concern about is your offence-taking that the portalspammer is called a portalspmmer, and a shitstorm is called a shitstorm. If you showed a fraction of the same concern for consensus, rather than describing it as "kool-aid" and objecting to calls for RFC, then I would be more inclined to take your complaints seriously. --BrownHairedGirl (talk) • (contribs) 00:49, 3 May 2019 (UTC)
I'm confused. Again. It seems like you mean you'll only listen to me on topic A if I first agree with you on topic B.--Paul McDonald (talk) 01:43, 3 May 2019 (UTC)
For once, we agree! You are indeed confused. Very much so.
Nothing in what I wrote there was about you agreeing with me. It was about your failure to embrace the core policy of consensus. --BrownHairedGirl (talk) • (contribs) 09:53, 3 May 2019 (UTC)
Where or how have I failed to embrace the core policy of consensus?--Paul McDonald (talk) 13:22, 3 May 2019 (UTC)
Above, where you objected to the big decisions being made at RFC.
And at [5], where you wrote I've never been one to drink the consensus WP:KOOLAID. --BrownHairedGirl (talk) • (contribs) 23:41, 3 May 2019 (UTC)
I'm going to ignore the ranty-pants stuff above my post and just address the OP: I think this is clearly the way forward. While well-developed portals on sufficiently broad topics will still have a place (at least judging from the strong consensus to retain them in the RfC last year), they're clearly not viable as a generalized navigation system, and arguments are frequently made that our mainspace articles already have too many navigation features injected into them (excessive infoboxes, piles of navboxes at page bottom, distracting sidebars, redundant "See also" links, redundant categories, etc., etc.). So having the software, or some optional "gadget" adjunct to it, provide unobtrusive but better-engineered and more helpful navigation would surely be a boon, if done properly. I also agree with the gadget approach; the MW devs accept little input, even to fix crucial bugs. It seems unlikely to me that they'll implement something complicated, if it wasn't mandated by WMF, unless it is pre-developed and well-tested – handed to them on a silver platter, as it were. Many of the things we now take for granted on MW wikis, like the Lua-based Scribunto modules back-end that gives us a far more functional template system than we had in the 2000s, were third-party projects.  — SMcCandlish ☏ ¢ 😼  07:14, 5 May 2019 (UTC)
Two groups of editors with differing aims are trying to share one WikiProject. On the one side we have the portal enthusiasts, though the most prolific creator now concentrates on other areas. On the other side we have the substantial minority who !voted to ENDPORTALS. Even BHG, one of the more moderate deletionists who actually improves portals, feels that portals are by and large a waste of time. That's an awkward environment for anyone to work in. Certes (talk) 11:18, 5 May 2019 (UTC)
That's not an unusual situation, Certes. In a lot of areas where I work, there are editors with radically different approaches. Sometimes that produces a permanent battleground, but other times it leads to a healthy compromise.
I think we have the makings of that compromise here. I would have preferred ENDPORTALS to conclude with a yes, but I accept that it didn't. Other editors would have preferred the sort of proliferation of portals that happened last year, but accept that consensus rejects that too. So the middle ground is obvious: fewer, better portals, actively maintained. That's what we are shuffling towards for now as we clear out the chaff. --BrownHairedGirl (talk) • (contribs) 12:25, 5 May 2019 (UTC)
What is meant by "better portals" is still up in the air. Does it mean politicians, locations with many places, just plain subjects...--Auric talk 13:26, 5 May 2019 (UTC)
Yes, that question of appropriate topics is undecided, as is the more fundamental question of what portals should try to do and how they should do it. This housekeeping phase is just removing the clearly-no-good: narrow scope, abandoned, full-automated etc. --BrownHairedGirl (talk) • (contribs) 14:22, 5 May 2019 (UTC)
@Auric, BrownHairedGirl, Certes, and SMcCandlish: At the moment we're continuing to decide on a case-by-case ad hoc basis at Wikipedia:Miscellany for deletion, and I would urge more project members to contribute there. And I don't mean mindlessly voting "Keep" on everything, that's as unhelpful as mindless delete votes. BHG's compromise is a good summary. Espresso Addict (talk) 15:03, 5 May 2019 (UTC)
"Awkward environment" is an understatement. It is not normal at all for persons generally trying to delete the output of a project, to see its members censured, and to see the project brought to an end to be dominating the project's talk page. That's rather like a Republican showing up at a Young Democrats of America meeting and trying to run it. It's especially inappropriate when the same side is using every other available venue pursue their aims already, and sharply critical of actual project participants even putting out their own newsletter to each other.

That said, my own concerns are primarily about the disruptively WP:FAITACCOMPLI- and WP:GAMING-based, and overly personalized and bad-faith-assumptive, anti-portal activity outside this project page, but it's really all part of the same battlegrounding pattern. It's making for a hostile working environment not just an awkward one. Part of why I've been comparatively inactive on WP over the last month+ is the fact that every time I check back I see another tsunami of portal-related WP:DRAMA, despite me not even being deeply involved in portals. It's rather like living next door to people who generate a lot of suspicious noise in the middle of the night, every night. At some point, one calls the cops if knocking on the door and asking them to stop freaking out the entire neighborhood doesn't work.
 — SMcCandlish ☏ ¢ 😼  19:48, 5 May 2019 (UTC)

  • I think Portals and WP:Outlines were ideas had great merit, but they have not proven workable. For both, I now believe the cost-benefit is a fail for all but the Main page and the top maybe dozen Portals. The best part of the motivation was navigation, but the costs of dangers of content forking and editor bias outweighs the navigation benefits. I was enthusiastic about auto-portals, but that experiment resulted in a negative reception.
How about graphically auto-mapping article connections? Something like File:Social Network Diagram (large).svg. Attempt to map connectivity between articles based on wikilinking. I think it would be important to remove navigation template linking from the calculations, I have already seen that navigation templates have rendered Special:Whatlinkshere as unreliable. --SmokeyJoe (talk) 00:28, 7 May 2019 (UTC)

Portal pageviews

Latest comment: 4 years ago13 comments5 people in discussion

In a discussion above, @Espresso Addict wisely suggested that it would be helpful to have a list of pageview counts of portals.

I agreed, and offered to make a bot request. In preparing the bot the request, I did a little homework, and found that the bot request is un-needed, because there is already an interface to do what's needed: https://tools.wmflabs.org/massviews/

I fed it with Category:All portals, and and set the date range as 01/01/2019 - 28/02/2019, i.e the first two months of 2019, before pageviews began to be distorted by intensive scrutiny from editors.

Here's the direct link to the list of pageviews for each portal in the first 2 months of 2019. Sorry! Initial link was wrong. Now corrected to show Jan–Feb. --BHG (talk) • (contribs) 12:32, 29 April 2019 (UTC)

Note that of the 1504 portals which it successfully checked, the median daily average pageview for the is 11 views/day ... i.e. the midpoint in the series is 11 views day, or phrased differently half got more than that, half got less. I will now work on some breakdowns. --BrownHairedGirl (talk) • (contribs) 13:49, 28 April 2019 (UTC)

  • Adding portal links to various pages tends to improve page views. I've noticed main article pages at times that have a direct corresponding portal lacking any links to the portal at all. Sometimes links are only present in a buried, collapsed nav box. More links = more page views. More visible links = even more page views. North America1000 14:11, 28 April 2019 (UTC)
  • @Northamerica1000, in some cases, linking may help marginally. But in 2017/18 I used Template:YearInCountryPortalBox to automatically add links to multiple portals from over 70,000 category pages, and the result was no detectable change in views.
In this comment[6] at another discussion, I compared the hit-per-link for portals to some articles. My conclusion there was that it seems to me that on a pageviews-per-link ratio, the portal is underperforming by a factor of about ten.
So far as I can see from a lot of checking and comparisons, the reason that almost no readers visit portals is that almost no readers want to visit portals. Even the portals linked from Wikipedia's absolute prime advertising pace (i.e. top right of the front age) massively underperform. --BrownHairedGirl (talk) • (contribs)
  • Those portals atop Main page sure get a lot of views. Quite a lot. The Arts portal gets more page views than the article itself! It's all about visibility; and the more the better. North America1000 14:43, 28 April 2019 (UTC)
  • Also, I thought this page was about improving portals, rather than focusing upon ways to further their mass deletion. Moreover, portals should be considered on a case-by-case basis, rather than upon simplified averages and bean counting. Just saying. North America1000 14:51, 28 April 2019 (UTC)
  • @Northamerica1000, I have created over 100 discussions to examine portals on a case-by-case basis, and you repeatedly complain about that.
Now when I post some statistics to inform those discussions, you complain about that too ... and make the thoroughly bad faith assumption that it was motivated by focusing upon ways to further their mass deletion. You know that is untrue, because in the first line of this section I noted that I offered the data in response to a request by Espresso Addict. It was not my idea -- it was EA's idea, and you knew that when you tried to smear my motives.
There is a 4-letter word for people like you who smear others on the basis of assumptions which you know to be false. Clean up your act.
Now to your comment about the portals linked from the front page. The rest of this is excepted from a reply I made to @Bermicourt on their talk:
That point you make about portal promotion is interesting. Luckily, we have some data to test it: the 8 broad-topic portals linked from the top right of the front page.
Remember, that's the absolute prime spot for reader attention. If (God forbid!) Wikipedia ever took to selling space for banner ads, that slot would command the highest price. So links there should be getting a high hit rate.
But see right the daily average hit rate for those 8 portals for Jan–Mar 2019: 1,335
Compare that with a median range of 30,000 to 50,000 for recent TFAs. OK, TFA is a bigger, more eye-catching block. But still, that's about a 25:1 ratio. I looked at a recent TFA, Albert Pierrepoint: 83,227 hits on the TFA day (30 March 2019), but a Jan–Feb 2019 daily average of 847; that 63% of the big-8 portal average without being anywhere near the front page.
The DYKs are below the fold, and each is individually less much prominent than the DYK. But your description of individual DYK hits (which matches my experience) is that they each got more way more daily hits than the avg portal, despite being there for only half the day. (Or is it 6 hours?)
Or compare those 8 portals with the much less prominent link to the Featured content near the top of the left-side menu: 6,591. (Yes, it's a portal, but it's not advertised as such)
So it seems to me to be fairly clear that when offered a clear choice of portals or other types of content on the front page, portals are a relatively slow seller.
We could do similar analysis of portals linked from navboxes vs articles linked from navboxes, and I'm pretty sure that we'd see similar results: the portals get v low hit rates.
In the discussion at MFD:15 automated portals built on a single list, I wrote two long posts about why this is so. Basically, it's because an ordinary en.wp head article is so very good for navigation that a portal has to be truly exceptional to do better. And most portals, even on broad topics high on the vital article list, are not exceptional.
For example, I just made my first ever visit to Portal:Europe. That's a level-2 VA, chock full of highly-developed nations, where en.wp does a pretty good job of documenting two millennia of history. It's a much better maintained and developed portal than most, but it's still kinda rubbish as a portal. About 5 over-long snippet of articles, but no navigational pathways to follow. Instead of being a gateway to explore the huge collection of articles non Europe, it's a slim single-issue glossy mag.
So little wonder that Portal:Europe averaged 61 pageviews/day in Jan–Mar 2019, while the head article Europe averaged 8,788. That a 144:1 ratio, just like much smaller topics.
The data is the same wherever I look. For any given level of promotion, portal links are much followed than other links. --BrownHairedGirl (talk) • (contribs) 17:31, 28 April 2019 (UTC)
  • So, the point is, BrownHairedGirl just wants all portals deleted, vis-a-vis WP:ENDPORTALS? I'm not sure what your overall stance is. North America1000 17:36, 28 April 2019 (UTC)
    • NAIK, it's disgraceful that you seem unable and/or unwilling stop putting words in my mouth, and actually discuss the matter in hand. It's highly uncivil, and it is disruptive conduct.
The two points I was making here are very simple:
  • The statistics show that the overwhelming majority of portals have very low viewing rates
  • That the research I have done shows that links to portals are much less likely to be followed than links to articles
That's it.
So please do me the very basic courtesy of actually looking at the figures if you are interested in them ... and if you're not interested, do something else rather than sniping. --BrownHairedGirl (talk) • (contribs) 18:29, 28 April 2019 (UTC)
I made a point in a specific MFD discussion which may be relevant here. I'd been looking at how German Wikipedia uses portals and noticed that e.g. Portal:Bahn (=Portal:Railway) gets twice as many views as our Portal:Trains even though German Wiki has a smaller audience. On checking their links from mainspace, I noticed that Portal:Bahn has relatively few article links (only 4 main topics plus some random articles which are clearly not following the conventions), but appears to be linked from all the category pages. In other words, it is being used in a different way - more as a tool to complement (and sit above) the categories (as well as being used to aid WikiProjects). I've only had a quick look, so more research required, but that may be a better way to go as far as the reader-facing usage is concerned. So I don't see why portals, which are not in mainspace anyway, are being expected to compete for hits against reader-facing articles in mainspace. Any thoughts? Bermicourt (talk) 19:05, 28 April 2019 (UTC)
  • Very quick comment: Not read the above discussion carefully yet, but the list is absolutely fascinating! Thanks to BrownHairedGirl for coaxing it out of the software. Some off-the-cuff thoughts...
On a quick scan, I think Portal:Companies is top of the hits for those not linked off the mainpage – which is interesting, given how sparse & eclectic its contents are (my comment on the 23rd in Wikipedia:Miscellany for deletion/Mixed bag of group portals "Those advocating for deleting all individual company portals in favour of the top-level one might care to assess Portal:Companies, with its sparse & in some cases peculiar selection of articles, dull design and run of missing reference errors at the bottom.").
BrownHairedGirl: does the median change significantly if one excludes all the portals linked from the main page? ie 1–11 in the list I got.
On main-page hits generally: These have been declining overall for a long time, which is usually put down to a greater proportion of mobile views. Afaik, mobile removes some elements, which might include the boilerplate including all the portal links (I never use mobile). The DYKs have mainly been on a 24-hour cycle recently, except for 1 April. In my experience, average DYK hits have gone down greatly over the years; one used to be able to get >5000 in 6–8 hours by a reasonably snappy hook, especially in the top pictured slot; now even on the current 24-hour rotation, they can be numbered in the low hundreds. DYKs are not below the fold on my laptop. They're all visible. I even get all of today's featured list if I maximise. Even my other low-res screen usually gets the top half of the DYKs.
I wonder if main-page portal hits could be enhanced by adding an image? Or individual graphics? I agree they are prominent but they're very bland in appearance, and the other sections all usually have images.
@Bermicourt: Portals are, for some reason, much more successful in several non-English wikis, not just the German one. How many hits do the category pages get? I didn't think average readers often clicked on categories, but I've never seen that data.
On the other discussion, can I just say: Please can we try here on this page to focus on how we might make portals more attractive/more useful, how we might drive traffic towards them, and which portals need attention most urgently given the hits data? If we're always discussing the Imminent Demise of All Portals, OMG!!! then we're never going to make any progress. Espresso Addict (talk) 04:53, 29 April 2019 (UTC)
@Espresso Addict: I am sorry, I screwed up in posting the link. It was for recent hits, which are wildly distorted by all the recent views by editors at MFD etc. I have corrected the link above, and here it is again: Jan–Feb 2019 portal pageviews. Grovelling apologies for my stupid error.
A few other points:
  • I referred to the median being 9 views/day. That's the mid-point of the ordered dataset, and it's v different to the arithmetic mean. The mean. Quick extreme example to illustrate: data set has 5 values: 1, 2, 2, 3, 1000. The median (midpoint) is 2; but the mean is 201.6. The median doesn't get distorted by outliers, so provides a better guide to the most common value.
  • So the 11 most viewed at the start barely move the median. With them included, the median is #754 Portal:Luxembourg, with 677 totals view, i.e. 11/day ... but without them, the median is #760: Portal:Pervasive developmental disorders with total 672 views, 11/day
  • Main page portal views might be enhanced by adding a wee graphic. I would oppose that unless there was a broad consensus that the portals concerned were of sufficient navigational benefit to justify such promotion. Looking at the leftmost 3 of the set, I'd say that Portal:Arts and Portal:Biography are competent examples of the magazine-style portal, but that Portal:Geography is mediocre. I don't think that any of them is a good enough navigational tool to deserve more promotion; I think that all are currently much too highly-promoted. I know that you do like the magazine-style, so we're going to disagree on that; but any further promotion should be based on a broad consensus that those portals do actually offer very high value to the readers.
  • Overall, the dataset is damning. Only the top 56 portals (i.e. 3.7%) exceeds 100 pageviews/day. The top quartile begins at 23 pageviews/day. The gargantuan Portal:San Francisco Bay Area, with over 1100 subpages get only 83 views/day.
  • Category viewing figures are a poor comparator, because the category system is highly-distributed with multiple entry-points, whereas portal pages concentrate topics on as= single entry-point. There are literally millions of categories, but only ~1500 portals.
Hope that helps. --BrownHairedGirl (talk) • (contribs) 13:37, 29 April 2019 (UTC)
I don't think any of my above comments were affected by the error. I was working on a long comment here which will have to go back to the drawing board; some of the observations did seem a little peculiar. (I've self-reverted the comments I made based on them to MfD, if anyone's confused.)
On the three main-page-linked ones you mention: The births and deaths in On This Day in Biography are great; however it only excerpts 12 bios, one per month. It doesn't look as if anyone is updating it annually, unfortunately; I'd suggest that's one priority. I like the audio clips in Arts, but otherwise it's bland. Geography looks weird; that enormous image at the top certainly wasn't in the featured version, not sure when that crept in! Geographical portals overall seem to do rather more poorly than I had envisaged. Also, Society gets surprisingly few hits given the plum placement. One thing we were talking about when the Featured Portal process was running, as I recall, was rotating in one of them in with set at the top, as Portal of the Day. I don't recall now whether the plan was to put it in place of Society or All portals.
On categories, I wasn't trying to use them as a comparator to portals, which I agree they are not, but to respond to Bermincourt's comment above about the German Wikipedia placing portal links predominantly on category pages.
I am wondering what's happened over time with the page views. My former featured portal used to get nearly 100 hits per day before the process was terminated, so it is possible to drive traffic towards a minority topic. Espresso Addict (talk) 14:43, 29 April 2019 (UTC)
@Espresso Addict: Search engines happened. People seldom use Wikipedia's native navigation systems when Google puts the relevant article right at their fingertips. Google's Knowledge Graph is also the primary reason for the decline in mainspace article views, since people often only need to read the lead text to get the info they need, and move on. Non-mainspace pages will have felt this effect even more. — AfroThundr (u · t · c) 03:43, 8 May 2019 (UTC)

Category:Portal with subpages tracking

Latest comment: 4 years ago26 comments6 people in discussion

Earlier today I created Category:Portal with subpages tracking, plus a set of subcats. This is an aid to identifying manual portals by the number of subpages they have. (Similar to Category:Automated portal pages tracking, which is for automated portals)

The tracking categories are automatically-populated by the Lua modules from which the portals are built. Please note the disclaimer on each those tracking categories. Software limitations mean that they should be used only as a starting point for careful scrutiny of the portal's wikitext and its list of subpages.

Limitations

Most such portals have more than one list of "selected foo", but the software handles each set separately and knows only about the set which it is currently processing. So if a portal has 4 selected biogs and 9 selected general articles, it will be categorised in both Category:Random portal component with 2–5 available subpages and Category:Random portal component with 6–10 available subpages. However, if the same portal had 6 selected biogs and 7 selected general articles, it would be categorised twice in Category:Random portal component with 6–10 available subpages ... but since the category system ignores duplicates, it would just appear once in Category:Random portal component with 6–10 available subpages. Caveat lector

Bonus

The number of subpages in each section is set by editors using the "max=" parameter in {{subst:Random portal component}}, {{Transclude random subpage}}. If I had simply used that parameter to build the tracking categories, then the code would have been simpler, but I soon realised that would create an unhelpful vector for miscreants to game the system by setting a "max=" higher or lower than than the actual number of available subpages, to make the portal look much more complete or less complete than it really is.

So I rejigged it actually check for the existence of subpages. The handy bonus from this approach is that the module can compare the number of subpages found with the value of "max=", and categorise the portal in Category:Random portal component with fewer available subpages than specified max or Category:Random portal component with more available subpages than specified max, as appropriate. If everything is properly maintained, both those categories should be empty ... and as of now they contain a combined total of 115 pages. (purge this page to get the latest count)

The downside is that has required reducing the level of detail given about on very big portals.

Huge portals

Note that I had initially built the system to provide more finely-grained breakdown of portals with over 50 subpages, grouping them 50–100, 101–200, 201–500, 501–1000, and over 1000. However, this caused Lua overload on portals with large numbers of subpages, e.g. Portal:San Francisco Bay Area with its 1,159 subpages. So I tweaked it to stop checking once it finds over 50 subpages.

So it now helps positively identify large portals, but it doesn't separate out the huge or humungous portals. Large is the biggest grading.

Uses
  1. This will help portal editors to identify portals which already have good coverage, and also to spot on broad topics which should have more sub-pages.
  2. This also helps to identify never-really-started portals, which are possible candidates for deletion. See e.g. Portal:Kandahar, now being discussed at WP:Miscellany for deletion/Portal:Kandahar; that was the portal which prompted me to build this tracking system.

Hope this helps. --BrownHairedGirl (talk) • (contribs) 17:32, 29 April 2019 (UTC)

  • Question It looks like certain portal subpages are themselves also being categorized, rather than just the top portal; any way to limit this just to the top portal page? UnitedStatesian (talk) 17:37, 29 April 2019 (UTC)
    • @UnitedStatesian, that would be a very simple piece of code to add. When I saw some subpages being categorised, I had considered adding it ... but I decided to wait and then check whether all of the subpages were in fact subpages, or just misnamed portals. The categories may yet not be completely purged, but here's the list of pages so far:
  1. Portal:Beer/Sandbox
  2. Portal:Human body/Cardiovascular System
  3. Portal:Human body/Integumentary System
  4. Portal:North America/Geography
  5. Portal:Human body/Reproductive System
  6. Portal:AC/DC
  7. Portal:Canada/Wikiprojects
  8. Portal:Speculative fiction/Horror
  9. Portal:Speculative fiction/Publications
  10. Portal:Speculative fiction/Fantasy
  11. Portal:Speculative fiction/Science fiction
  12. Portal:Heraldry/Selected article
  13. Portal:Japan/Geography
  14. Portal:Africa/Countries
  15. Portal:Speculative fiction/People
My plan to look check for pages with a slash in their titles would obviously generate a false positive on Portal:AC/DC, but I'm not sure about the others. Please would you be kind enough to check? --BrownHairedGirl (talk) • (contribs) 18:21, 29 April 2019 (UTC)
After checking, Portal:AC/DC is the only one that is an actual portal (and it is up for deletion). I think you can safely add your code. UnitedStatesian (talk) 18:30, 29 April 2019 (UTC)
Many thanks for the prompt check, @UnitedStatesian.
I will implement it now, with Portal:AC/DC hardcoded as an exception, 'cos I don't want to prejudge the outcome of the MFD. --BrownHairedGirl (talk) • (contribs) 18:50, 29 April 2019 (UTC)
Sub-pages now excluded. I screwed up a few times along the way, so the categories will be a bit unstable for the next few hour while pages get purged. --BrownHairedGirl (talk) • (contribs) 20:24, 29 April 2019 (UTC)
  • Comment. As noted above by BrownHairedGirl all sections are categorised separately. In terms of identifying good/bad coverage, this works rather counterintuitively where the portals have a lot more than one selected item, as larger portals IMO should. One of mine has ~9, depending on exactly what it is counting, and most old-style ones should have at least 4: articles, bios, images, DYK. Or is it not counting images/DYKs? What I'm trying to underline here is that there will be a mix of both well-developed and poor portals in both high and low categories, while the poor-to-mediocre ones with only one subbox will tend to sit in the middle. Espresso Addict (talk) 03:11, 30 April 2019 (UTC)
    • @Espresso Addict, sorry, I should have noted that it's not counting DYKs. I had to exclude them, because a significant dose of portals had high numbers of DYK pages which broke the Lua module. In any case, the number of entries on each DYK sub-page is variable, so it was a bit of an apples-and-oranges comparison.
So what the module is now doing is tracking sets of subpages whose title begins with "Selected". That will pick up "Selected articles", "Selected biographies", "Selected pictures", "Selected stripey things which go bump in the night" etc.
My interpretation of the data is that any set of subpages with less than 10 pages is weak, those with over 50 are strong, and that those with under 5 are poor. Obviously that may be offset to some extent by having multiple sets of subpages, but I don't see any way of checking that short of a bot trawling all the portal pages and doing a more comprehensive analysis. So the module is just collecting what data is available to it, and reporting that with big red caveats.
Actually, it has just occurred to me that I think there is a way that a different module could do a somewhat broader analysis. It might be a bit of a stretch for my hacker levels of Lua coding, but if this project settles on a few stable models of portals, it would probably be worth developing it to all a wee "portal info" link somewhere on the bottom of the page which could generate a quick report on the claimed number of subpages in each section.
(Personally, I think that the current many-subpages model of portal is a very bad idea which should be phased out, but that's another discussion). --BrownHairedGirl (talk) • (contribs) 12:31, 30 April 2019 (UTC)
@BrownHairedGirl: I don't know whether everyone is using "Selected"; some might be "Featured" or "...of the Month/Week/Day". (Some of those would have 365, obviously.)
My personal categories would be roughly <8 poor, 8–12 low, 12–15 moderate, 15–20 fair, 20–45 ideal, >45 too many, should be split. The featured portal process used to broadly require 20 in all boxes; and a minimum of 2 textboxes plus images, as I recall, though there were exceptions where there were more than the minimum number of boxes. OhanaUnited was the arbiter.
DYKs are problematic; I hand-assemble sets of 4 or 5 with an image, but others put individual DYKs into subpages and let the randomisation pick a set. And they do tend to accumulate in a large numbers, especially if someone's gone round specifically searching them out from the archives. A proper DYK display is a lot of work, believe me; much easier to add textboxes and especially images.
A detailed bot report would be interesting. Sometimes it's hard to see how many pages there are, especially where there's no see-all-on-one-page feature. The max= figure is not always correct (and can go either way). Espresso Addict (talk) 13:10, 30 April 2019 (UTC)
@Espresso Addict, your assessment of counts makes sense. Your groupings don't quite align with the thresholds I used, but are not wildly divergent, so I hope the current set is some help. If there is consensus for any particular grouping, I'd be happy to change the categories (it would take me about 20 minutes work to implement it, so not a big deal).
Yes, the max= figure can be wrong, which is why I didn't rely on it, and created the two tracking categories for anomalies (fewer pages than max and more pages than max). It looks like someone has already been doing some cleanup there, which is great.
I can see that DYKs take a lot of research. I am not persuaded that it's worthwhile; a more sophisticated search system than TTH's current implementation would probably have much better return on effort.
BTW, I just noticed that the tracking wasn't picking up portals which use {{Random portal component with nominate}}. So I fixed that[7], nad have purged the 116 portal pages involved. Sorry for the oversight. --BrownHairedGirl (talk) • (contribs) 13:38, 30 April 2019 (UTC)
Re DYKs, I don't see the point in throwing them away once done – that was one of the worst feature of The Transhumanist's reboots, IMO – but if anyone could write a really sophisticated finding tool it would be a lot easier than paging through the DYK archives by month one by one with a moderate number of search terms... But if someone can find something that gets all viruses/virals/virologists that aren't computer viruses or viral memes, and doesn't just lose all those including the word computer, deals with the fact that the viruses project actively won't tag virologists, antivirals & is ambivalent towards vaccines, and then persuade the Lua not to time out... Espresso Addict (talk) 13:51, 30 April 2019 (UTC)
@Espresso Addict, I certainly wouldn't support anything remotely resembling a blind cull. But even the good ones are maintenance headache, so in cases where search results come close to replicating the manual version, I'd support replacement. That would obviously require checking in each case and some override system to exclude false positives, but conceptually I think that is achievable in some cases. Viruses is probably example that wouldn't work because of the word's multiple primary meanings, but other topics such as some country names don't have many other major uses. e.g. Uganda overwhelmingly refers to the country, and sadly we don't have an extensive collection of DYKs relating to the ever-important encyclopedic topic of Ugandan discussions.
Now that I have moved on to more scrutiny of manual portals, I am horrified by the proliferation of sub-pages. It's a big maintenance nightmare, as well as an huge attack vulnerability, and a breach of WP:REDUNDANTFORK. I don't intend to do any sort of cull, but some ways needs to be found to massively reduce the number of subpages. It's another example of an area where TTH rightly identified a problem, but implemented a change without enough analysis and no broad consensus that it was actually a good solution. So, no change without lots of discussion and testing ... but e.g. Special:PrefixIndex/Portal:San Francisco Bay Area is a problem to resloved. --BrownHairedGirl (talk) • (contribs) 16:45, 30 April 2019 (UTC)
That's a euphemism I'd never encountered, thanks!
I'd be interested in what the community thought of proactive semi-protection. I don't think I've ever seen a positive IP edit to a portal subpage. One might also fully protect BLPs. To be honest, though, even when my former featured portal was getting 100 hits/day, there wasn't a great deal of vandalism.
I also would like to suggest the idea of using the head subpage – where all the 1–n are listed – as the source. That would greatly reduce the number of necessary subpages. Espresso Addict (talk) 16:57, 30 April 2019 (UTC)
Regarding pre-emptive page protection, current English Wikipedia consensus doesn't favour it, and exceptional cases are those that are vandalized a lot, so portal pages probably won't make the cut.
I do not understand how the older subpage system works, so forgive me for mixing up apples and oranges, but your first sentence triggered an idea, which may or may not be what you're thinking of. Could the helper templates be used to create a one-page portal that draws from a subpage for its source data? This would simplify maintenance by having one subpage to update (e.g. links to relevant articles and a photo gallery for the helper templates to get its info), but not tightly couple the portal page to the specific formatting and layout of mainspace articles. isaacl (talk) 17:32, 30 April 2019 (UTC)
@isaacl, I think that a much better solution would be to stop forking content, and instead adapt some of the modules which TTH wrote to just grab the lede from the article. So manually create a list of selected articles, but let software do the rest.
Better still, dump the magazine-style format, and just list a cluster of selected pages, possibly accompanied by some metadata like the short description data in the article. --BrownHairedGirl (talk) • (contribs) 21:16, 30 April 2019 (UTC)
You mean create a one-page portal that doesn't use any subpages? Sure, that's also feasible. If it were desirable to keep some of the functionality to rotate different content on the portal, then having a separate page to list the content might be helpful, but it probably doesn't make too much difference versus just listing the content on the portal page directly as template arguments. isaacl (talk) 21:29, 30 April 2019 (UTC)
Sorry for being late to the party (been dealing with matters related to floods in central and Eastern Canada at work). I didn't have time to read through all the comments above so I'll just reply to the portion where I was pinged by User:Espresso Addict. Featured portals should have at least 20 items. I want to emphasis on should. Under 15 means there's probably not enough depth in that area to merit its own section. But I'm not chasing numbers either. I would rather have 18 FAs/GAs as selected articles instead of 25 selected articles but the number is padded by 10 stubs and start-class. And it's very rare to have too many items lol. I echo what Espresso Addict said regarding DYK. It's very tricky to deal with and add contents. You want to avoid overlapping with the selected articles or images' topics. But you also don't want to pick a topic that the hook is too obscure or not interesting. Often times, it's impossible to find 20 DYK items and I will let it slide. OhanaUnitedTalk page 01:23, 3 May 2019 (UTC)
Thanks, OhanaUnited. I think we always differed on how much weight to put on quality as opposed to importance. The advantage of FA/GA/FL is that someone else has reviewed the article in detail; if one includes B-class/below one has to do that oneself, which is time-consuming but probably good for the project, as the article will tend to improve during the review. I'd not advocate adding Starts unless one could first upgrade them to at least C-class.
I had not thought of DYKs duplicating selected articles as a problem, except where the header image is duplicated. In the ideal world, sets with a range of DYKs that are actually interesting would be great, but that isn't what the main-page project is generally generating these days. Espresso Addict (talk) 09:42, 3 May 2019 (UTC)

Counting redirects

  • Question: does the categorization exclude redirects in the count? I do not think these should be included. UnitedStatesian (talk) 14:40, 30 April 2019 (UTC)
  • @UnitedStatesian, no it doesn't check whether a page is a redirect. So unfortunately, redirects are included.
I would like to exclude them, and the coding to do so would be very easy: just three lines of code using the Title objects property "isRedirect". Unfortunately, that's listed as one of the Expensive_properties, so if I call that too many times the Lua module is halted, leaving a redlinked error instead of output.
This overuse of one of the Expensive_properties is what caused the module to break on large sets of subpages, sadly causing you to get yelled at in MFD:State-level road portals. If I enabled redirect checking, I would double the number of calls to expensive properties, so I'd have to further reduce the number of subpages checked, which I think would severely degrade the utility of the tracking.
So I think that the remedy is to delete the redirects, after checking whether they are needed. --BrownHairedGirl (talk) • (contribs) 15:24, 30 April 2019 (UTC)

Suggest change

As mentioned by another editor above, I know of many portals that use "Featured . . ." rather than "Selected. . ." in their subpages. Any way to add that second word in generating the count? UnitedStatesian (talk) 17:25, 1 May 2019 (UTC)

@UnitedStatesian, it's not even a SMOP.  
Please can you point me to some examples, just so I can check that I understand the usage correctly? --BrownHairedGirl (talk) • (contribs) 02:51, 2 May 2019 (UTC)
@BrownHairedGirl: here's one and here's another UnitedStatesian (talk) 12:30, 2 May 2019 (UTC)
Thanks, @UnitedStatesian. Now implemented in these 2 edits: [8], [9]. --BrownHairedGirl (talk) • (contribs) 18:00, 2 May 2019 (UTC)

Category:Portal with image subpages tracking

I have just tweaked the modules again[10][11] to make them track sets of images separately from other types of subpage: see Category:Portal with image subpages tracking and subcats.

This will track sets of subpages whose title includes the word "selected" and one or other of "image" or "picture". I occurs to me that there may be sets of subpages which use other titles for a set, possibly with words such as diagram, drawing, or photo. If anyone can identify such sets, please let me know and I will add those terms to the checklist.

As usual, it may take up to 24 hours for the portal pages to be purged, and until then these categories will under-report the number of pages. --BrownHairedGirl (talk) • (contribs) 15:06, 8 May 2019‎ (UTC)

A milestone: less than 1500 portals

Latest comment: 4 years ago14 comments5 people in discussion
Σ Portals
~ 538
As of 30 Apr 2024 02:00

A few hours ago, the total number of pages in Category:All portals dropped below 1,500 for the first time since the tide of automated portals began to surge in mid-2018.

The current count displayed on Category:All portals is "approximately 1,463". However, the category software has a long-standing bug in its counting mechanism; the actual figure can be got by using AWB: 1432.

I have placed a live counter on the right, but note that it is displaying the "approximate value".

I think this is good news. The spammed automated portals are nearly all gone, and cleanup is now focusing on long-abandoned portals which are woefully underdeveloped, and on the few remaining narrow-topic portals.

There are currently 166 portals tagged for MFD, with 1,264 not currently under discussion. That figure of 166 is well own on the 250+ of a week or two back, and I think that the 166 includes some "zombie tags" from old discussions. Also a significant number of current discussions seem unlikely to close as "delete". So, allowing for some more nominations, I expect that the total will begin to stabilise around the 1200–1300 mark.

Before long, the drama will be reduced to a trickle, and this project can get back to improving portals and working towards new broad-consensus portal guidelines. --BrownHairedGirl (talk) • (contribs) 03:48, 2 May 2019 (UTC)

@BrownHairedGirl: What are your views on those remaining automated portals which are not currently at MfD? I have started improving them, but if you plan to MfD them or revert them to non-automated old versions then I'll stop editing pages which are about to disappear and do something else. Certes (talk) 10:18, 2 May 2019 (UTC)
Me too. I'm hesitant to do much more improvement on portals until the smoke clears and there appears to be a working consensus in favour of the sort of improvements to the project and its portals that we've discussed before. Bermicourt (talk) 10:50, 2 May 2019 (UTC)
Here's a radical idea: transparency. Which ones are you thinking of working on, and we can have a pre-discussion here. At the same time, here's my transparency about what I'm thinking has yet to come to MfD (and which I am starting to think about preparing):
  • there are still a few performers/politicians/companies/products that, because of narrowness of topic, would not, I think, survive MfD based on previous discussions.
  • Other User:Abyssal portals, besides the ones already at MfD, that do not meet the breadth-of-subject-area requirement
  • We still have a bunch on individual cities under 500,000 population
  • Religious denominations outside the major subgroups of the worlds major religions
  • Ethnic groups. This is a new one, but my first look is that most of these are in a sorry state and have breadth-of-subject-area issues.
  • At the same time, I think there is little value at this time bringing to MfD any portals on smaller countries, or on subnational political divisions other than smaller cities (i.e., states of US/Germany/Australia/Philippines/India, UK counties, etc.), so don't hold off working on those because you fear an MfD from me.
  • And is anyone thinking about any new portals? I think some of the TTH ones on broad subjects could support a recreated portal.
I of course welcome comments on the above in advance of any MfD discussion that may or may not ever happen. What are other folks thinking? UnitedStatesian (talk) 12:16, 2 May 2019 (UTC)
My current portal task has been working through this search improving DYK and ITN search patterns, but I have paused awaiting news on their prospects for survival. Certes (talk) 12:27, 2 May 2019 (UTC)
@Certes, Bermicourt, and UnitedStatesian: I have set out below how I select portals for MFD. Basically, I am triaging to look for clearly bad. Beyond that, I think we need broad discussions about what portals are for, how they should do it (see MFD:Portal:Ireland#4bigquestions) and then which topics should have them.
I personally would like to see the consensus settling on: a) hybrid of the outline model of e.g. P:Harz Mountains and a little of the magazine model, but no pure magazines; b) deprecating the content-forked-subpage model; c) much fewer, better portals, probably numbering in the low hundreds. (I'd prefer 30–100, but think that's probably unachievable)
However, any such big changes require a broad community consensus. Those are not matters for MFD, so I do not propose such things at MFD, and I oppose them if others try using MFD for that purpose.
But I do think that creating new portals right now would be a great folly. That broad consensus is needed first. --BrownHairedGirl (talk) • (contribs) 15:16, 2 May 2019 (UTC)
PS Sorry, I didn't answer Bermicourt's question What are your views on those remaining automated portals which are not currently at MfD?
My take on them is that:
  1. some automated portals are so-called "restarted" manual portals. In those cases, it may be worth restoring the manual version, if the manual version is not junk (which it often was, hence the conversions)
  2. Automated portals which are just a fork of a single navbox are a clear delete, per consensus of the mass nominations one and two
  3. Automated portals which grab links from a non-list article should be killed with fire (see e.g. MFD:Portal:Lusaka)
  4. Automated portals which are just a fork of any other single page also are a clear delete in my view, tho some editors have contested some of that
  5. Automated portals which build their list by aggregating multiple pages may be redundant if e.g. all those pages are transcluded in one place (e.g. if Portal:MyNiceTown builds its list on Template:MyNiceTown districts + Template:MyNiceTown history and both are transcluded in the article MyNiceTown, we have redundancy.)
  6. An automated portal which uses a curated list of topics that would make a good navbox should be deleted and replaced by a new navbox
  7. An automated portal which uses a well-curated list of topics that represents a subset of the best-quality and most significant articles in a wide topic is by far the vest way of creating a magazine-style portal. I am not a fan of the whole magazine model, but it has many fans, so unless and until there is a consensus to deprecate that model, this is a vastly better way to implement it than the hideous, abominable, bloated, sprawling subpage model. It a) avoids content forking; b) it is massively easier to build and maintain; c) it is better for readers, because it doesn't require a refresh.
Hope that helps. --BrownHairedGirl (talk) • (contribs) 16:32, 2 May 2019 (UTC)

OK, here's how I am working at the moment. I am looking for portals which fit one or all of these criteria:

  1. Broken
  2. Abandoned
  3. Narrow scope
  4. Automated, but redundant 'cos it draws its article list from a single source (making it a fork); usually a single page, but sometimes multiple pages which are transcluded in one place
  5. Manual, but with a too small a selection to be useful to readers

The more of those attributes that are present, the more likely I am to MFD. e.g. my most recent nomination is MFD:Portal:Daman and Diu, which matches criteria 1, 2, 3 and 5.

Where scope is narrow and/or Wikipedia coverage maintenance is poor, I advocate outright deletion. In the other cases, I advocate WP:TNT: delete this, but don't necessarily preclude creation of a better portal on the topic.

Right now I am working through Category:Random portal component with less than 2 available subpages. This takes some scrutiny, because many of the portals there have more than one set of subpages, so the total count isn't too dire.

I also have list of random city portals which look to me to be in possibly poor shape, so I will do some more analysis. Where possible, I look for tightly-bound sets with multiple shared attributes, to allow for coherent bundling ... but I'm not finding so many bundles right now.

My main starting points for research have been the tracking categories I created: Category:Automated portal pages tracking+subcats, and Category:Portal with subpages tracking+subcats. However, 294 of the portals in Category:All portals are in neither of those category trees, and that needs investigation.

Hope that helps. --BrownHairedGirl (talk) • (contribs) 14:26, 2 May 2019 (UTC)

That's helpful; thanks. It sounds as if most of the pages I intended to repair or improve will be deleted anyway, so I can be more helpful in other areas of Wikipedia for the time being. I'll look back when the dust settles and see if I can improve any portals which remain. Certes (talk) 15:38, 2 May 2019 (UTC)
@Certes, BrownHairedGirl, and UnitedStatesian: thank you for those helpful comments. Let me try and answer US's question about being transparent. I don't have any plans at the moment to create new portals, but hoping those I do manage are spared from the cull. I want to focus on steadily working through the existing ones I manage, fix any glaring problems, reduce red links (takes time as it involves creating new articles, but that's part of the benefit of a decent portal - having c. 5-10% red links to entice editors to "get creating") and automate those sections like "image of the month" which currently rely on manual intervention (and thus get out of date). I've not investigated the automated tools generated during the portal frenzy to see if any are useful, so that's something else I'd like to check out. I know we still have a range of views on total numbers of portals (~30 to ~2000) but I feel that if we focus on what portals are for and what makes a good portal we will converge to a range that we can all live with. But at least it won't be 4,500 and rising! Bermicourt (talk) 17:10, 2 May 2019 (UTC)
In order to get back to improving portals and working towards new broad-consensus portal guidelines it will be necessary to repudiate some of the arguments and tactics we have seen at MfD over recent weeks. For who will now want to make efforts in this direction if their product appears at risk of being clobbered over again?
Arguments: from forking – a concept that in Wikipedia applies to articles. From pageviews – readers searching for a broad topic are offered the article, not the portal: they haven't looked at a portal and decided to reject it as a presentation of that topic. From the absence of a named "maintainer" – not a requirement for any other type of page. It isn't just me. A chorus of editors have been making these points, to no avail.
Tactics: we have seen quite general discussions over portals initiated under MfDs of a particular portal, not stating on its face that a wider community debate was intended. At times there has been something approaching tag-teaming, with a handful of editors !voting delete on every one of a whole sequence of MfDs.
I'm wholly in support of the goal of a limited number of high-quality portals, acting as a "main page for a broad topic" as an introduction to Wikipedia for new readers. Time now for the deletion campaign to end and open debate to proceed: Bhunacat10 (talk), 19:58, 2 May 2019 (UTC)
  • Sorry, no dice. There are still plenty of portals that clearly do not meet the current guideline, and which I will continue to bring to MfD. You are welcome to help with that effort. UnitedStatesian (talk) 20:12, 2 May 2019 (UTC)
  • No dice from me either. I will also continue to MFD portals which meet the criteria I outlined above.
Yes, of course, some MFDs trigger generalised discussion, which is healthy: individual pages can throw up wider issues. XFD can't make a decision on those wider issues, but discussion at XFD can inform other decision-making processes.
Anyway, I'm delighted to hear that @Bhunacat10 is going to repudiate some of the tactics they have been using in recent weeks, like their assume-bad-faith rant and wild accusations[12] at MFD:Portal:Ireland; see my reply[13].
I wish Bhunacat10 well in getting their head around the idea that forking can applying many different contexts. Maybe then they can move on to next stage of recognising the overwhelming consensus against it mass deletions one, and two, and avoid follies like [14] comment.
Best wishes, --BrownHairedGirl (talk) • (contribs) 20:52, 2 May 2019 (UTC)

Now less than 1,350 portals

The category software bug continues to overstate the number of portals in Category:All portals. AWB shows that the current tallies are:

  • Total number of portals: 1,335
  • Portals tagged for MFD: 146
  • Portals without an MFD tag: 1,189

I had expected that the cleanup phase would leave us about 1350–1400 live portals. However, I am still finding one-of-each abandoned manual portals faster than I can write the detailed nominations needed to demonstrate their abandonment. These appear to be draft portals from the days before automated rotation of subpages, when editors were expected to manually write a new subpage each month, or preferably weekly ... but where updates stalled years ago. In the overwhelming majority of these portals, there has been no update since the portal was created, in some cases as early as 2005, but nearly all before 2012.

I had simply not expected to find that even after clearing out the navbox-forked automated portals, there would be so many long-term-abandoned portals. I don't know how many remain: the number may be as low as 50, or it may be several hundred. I will continue to bring them to MFD as long as I find then and have the energy to do so, and there are other editors doing similar cleanup. So my current guesstimate is that by the time all the remaining automated portals and abandoned or stillborn micro-portals are deleted, there may only be about 1000 portals left.

That will still include several hundred unmaintained manual portals whose selection of articles each amounts to less than ten pages, leaving them in a limited-utility category rather than the uselessness of the one-article portals. I am not sue that deletion is the best solution for those; I would prefer to see some sort of mechanism whereby after assessment such portals could be moved to a draft or incubator space, where they would no longer be linked from articles or categories (and therefore no longer presenting readers with seriously substandard portals), so that they would remain intact, allowing editors 6 months or a year to improve them before they deletion is considered. But no such incubator process is yet in place.

As I go through the lists, it is evident that there is a decade-long lack of systematic assessment of portals, which has allowed these abandoned pages to rot for so long without even being flagged as problematic. The cleanup process which I and other editors are now doing is basically catching up on a decade-long maintenance backlog. --BrownHairedGirl (talk) • (contribs) 15:37, 9 May 2019 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:WikiProject_Portals/Archive_11&oldid=901161705"