Jump to content

Wikipedia talk:Portal/Guidelines/Archive 8

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 5Archive 6Archive 7Archive 8Archive 9Archive 10Archive 11

Revisiting portal guidelines

In the wake of the recent failed RfC to delete all portals, and the current activity on Wikipedia:WikiProject Portals, are there any changes we need to make to the guidelines? · · · Peter (Southwood) (talk): 09:51, 23 May 2018 (UTC)

Myself and User:JLJ001 have been working on exactly this. We'll be starting an RfC here shortly. We'd appreciate your input. Kind regards, Cesdeva (talk) 10:57, 23 May 2018 (UTC)
On my watchlist, but ping me for specific input. Cheers, · · · Peter (Southwood) (talk): 12:29, 23 May 2018 (UTC)

RfC on new portal guidelines

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion.
A summary of the debate may be found at the bottom of the discussion.

RfC had ID 18D58A4 - Withdrawn to allow further work on the guideline. JLJ001 (talk) 08:46, 24 May 2018 (UTC)
In light of new developments in the portal namespace, it is time for new and improved portal guidelines. These guidelines will help guide the updating and ongoing maintenance of the portal namespace.

The in-situ guidelines were written in 2012, and have proven inadequate for guiding the creation and maintenance of portals. In addition, some parts of the guidelines were too restrictive and inhibited the evolution of portal design.

As such we have removed mandatory design elements from the draft policy, and intend to add those (less imperatively) into the instructions.

The new guidelines are intended to be sufficient to guard against unacceptable low quality portals, while not prejudicing against innovation (or already established markup). They will also guide editors into using the new transclusion templates to avoid content forks.

In short, this is a proposal to replace this with the content of this (minus the notices).
12:08, 23 May 2018 (UTC)

Proposers:
Cesdeva (talk) 12:08, 23 May 2018 (UTC)
JLJ001 (talk) 11:26, 23 May 2018 (UTC)

Survey

  • Support It's high time we update these guidelines to better reflect the changes that have occurred since their inception. We need to better iron out the criteria governing when, how, and for what topics a portal should (or should not) be created. I think we should also take a look at the notability suggestions from the recent RfC and other related discussions to find other good ideas to incorporate into the new guidelines. — AfroThundr (talk) 14:54, 23 May 2018 (UTC)
  • Oppose as I do not believe the proposed guidelines are better than the old ones. I point out some particularly problematic parts of the proposed changes that are nonexistent in the old version in my comment below. I think incremental changes would be better than attempting sweeping reforms in this case. — Godsy (TALKCONT) 20:04, 23 May 2018 (UTC)
  • Oppose. I don't see where this is coming from, and the 'content fork' notion is completely bizarre. I note the page refers to the main page as a good portal example, yet every item in that is extensively modified from the original articles, so as to fulfil its function as a portal. Espresso Addict (talk) 23:18, 23 May 2018 (UTC)
  • Oppose for the moment. Specifically:
    • Criteria #1 seems too restrictive, requiring a matching title. Portals can currently have multiple main articles (e.g. Portal:Molecular and cellular biology), or have scopes slightly broader than the main article (e.g. Portal:Australian roads), or be named inline with a parent portal (e.g. Portal:Australian cars).
      It also doesn't take into account that articles can be merged, or renamed, or have their scope expanded; none of those things happening should necessarily mean that portal is no longer valid.
      Perhaps have something more along the lines of "The portal topic must be notable; this is usually demonstrated by the existence an article of the same or similar." Which would still allow deletions due to lack of notability, without being unnecessarily restrictive.
    • Guidance on what content to include is hinted at in the lead introducing the reader to key articles, images, and categories but not actually detailed. Changing what's required, recommended, and optional shouldn't require removing content advice from what is a "content guideline"
    • The cleanup/deletion stuff should really just point to the existing deletion processes WP:CSD/WP:MFD; any changes to deletions should be made there. (As an aisde, per WP:ATD portals should be improved/completed if possible, rather than just taken to MFD)
    • Transclusion shouldn't be a requirement – if a portal is maintained at (or near) the old featured portal standards, then the continuing use of subpages isn't a problem.
    • Why the restriction on red links? Appropriate red links should be present per WP:REDYES, and the purpose of being "a bridge between reading and editing"
    • Not sure what is meant by Content #1, aren't all wikipages constructed from markup?
    • Style should be mentioned – i.e. the MOS should apply to the content within portal sections (but not strictly to the design of the portal itself). - Evad37 [talk] 07:30, 24 May 2018 (UTC)
I like your rewording of Critera#1.
I'm keen to oppose specific detailing of portal features being in the guidelines. Portals are in a state of design flux and I wouldn't want to prevent radically different user interfaces emerging.
Several editors have objected to the wording of the point on transclusion, mirrors and content forks. The intention of that part of the draft wasn't to go after sub-pages (personally I prefer sub-pages). I suppose the transclusion point could be dulled down slightly. I feel it's important to litigate against actual forking and mirroring full-articles.
What i meant by 'strict' markup was not excessively using </br> tags or &nbsp etc for layout purposes where stricter alternatives like margins or padding would suffice. I've not noticed that issue in portals I've looked at, but it definitely can happen and I felt it worthwhile to broadly allude to its inappropriate nature.
Red links are very counter to the navigational aspect of portals. That's why that point was made, otherwise I'd agree.
I wanted to include a mention of MOS, but couldn't quite pin down how best to do that. Cheers, Cesdeva (talk) 09:26, 24 May 2018 (UTC)
I have made a start on putting some of the point raised into the draft guideline, I would suggest the next RfC makes it clear where something raised here has not been included, and why. Perhaps some sort of explanation for each point. JLJ001 (talk) 09:40, 24 May 2018 (UTC)
  • Starting over was the right choice – I look forward to working with you on the draft. In the meantime, I've taken the liberty of removing erroneous information from the current guideline page, and have added a temporary lead, to prevent new portal makers from being misguided by the old out-of-date instructions. These changes will of course be replaced by the new guidelines to be adopted. And of course, feel free to revert.    — The Transhumanist   17:54, 24 May 2018 (UTC)
I agree with this suggestion so much that I used a time machine to go back in time nine hours to do it. In all seriousness though, we are redrafting taking the feedback into account and will start a new RfC at some hopefully not too distant date. JLJ001 (talk) 18:02, 24 May 2018 (UTC)
You are just too fast for me. :)    — The Transhumanist   18:08, 24 May 2018 (UTC)

Discussion

@AfroThundr3007730: I agree, although a challenge with the notability criteria is choosing non-arbritrary values for 'X'. Having a statistical formula for analysing portal topics would be great. Like: 

Σ/k=X

(# of topic sub-categories +  # of wikilinks in main article)/constant = value or rank

But more complex and with a way of giving more weight to certain inputs. I'm evidently not a statistician but there must be one around? A UI could then be coded that accepts input and returns an answer of 'topic worthy of portal'. Cesdeva (talk) 16:07, 23 May 2018 (UTC)

The argument could be made that there is no hard line for number of links to determine notability. I think proposed pages should be in the ballpark, but eligibility should ultimately be determined by the community. Still a tool like you suggested would be useful in finding out how close a candidate is. — AfroThundr (talk) 17:06, 23 May 2018 (UTC)
I agree that there should not be a hard line. However, a soft line would be useful. Anyone considering creating a portal could check against the soft line criteria to see whether the portal is likely to be viable. if it is borderline, more thought is needed, and arguments for support of the portal may be needed if it is challenged. Could reduce dramah. · · · Peter (Southwood) (talk): 05:43, 24 May 2018 (UTC)
Beside the opportunity for gaming, is there any relevance to the number of wikilinks in the main article?
This is an encyclopaedia: there must be a clear advantage to the reader from having a portal. For a portal to be more useful than the main topic article, there must be additional articles within the topic which are not reasonably suitable to be directly linked from the main article, otherwise the main article is sufficient and can directly link to all subtopics, making a portal redundant. This implies at least three levels in the topic - the main topic, the directly linkable subtopics, and the subtopics not directly mentioned in the main topic. I would suggest that this is the line we should be drawing- there should be some significant number of third level articles in existance. If there are four or more levels, the utility of a portal should be obvious. A good place to start would be to draw up a hierarchical outline list for the topic, and see how many articles are on it and how many levels occur. Levels of this hierarchy do not necessarily correspond with the levels of subtopic mentioned earlier, but may provide a reasonable proxy. · · · Peter (Southwood) (talk): 06:13, 24 May 2018 (UTC)

Moved from survey section.

  • Comment - "Portals that are clearly unfinished and have remained in a sub-standard state for more than 3 months should be nominated for deletion at MfD." I would suggest a notice at WT:WikiProject Portals be recommended then possibly a deletion discussion at MfD 3-6 months after that. It should also read "may be" instead of "should be". That aside, "There must be sufficient articles on the topic to make a portal worthwhile" is too vague. — Godsy (TALKCONT) 17:49, 23 May 2018 (UTC)
I see your point, but if a portal can sit for 3 months in a sub-standard or unfinished state, without anyone noticing, then it really does need a critical discussion about its value. MfD seems a good place for that. This is the kind of accountability that the namespace has been missing. Kind regards, Cesdeva (talk) 19:02, 23 May 2018 (UTC)
The fact it should be sent to MfD does not mean it will be deleted, only that it it will be removed if someone does not finish it in the week the MfD runs. This is actually much softer than the current situation, which could be to either send it to MfD immediately or to use CSD P2. three months is ample time to finish a portal to an acceptable minimum standard, a process which takes me less than 15 minutes. JLJ001 (talk) 19:27, 23 May 2018 (UTC)
That is the problem. It is miscellany for deletion, not miscellany for discussion or to prompt improvement. Unless we should not have a portal on a particular subject, it should not be nominated for deletion. If a topic meets the portal guidelines, its current state is irrelevant. Maybe a process for draftification should be developed. — Godsy (TALKCONT) 19:59, 23 May 2018 (UTC)
The proposer or creator of a portal is responsible for showing that its existence is justified. The topic may be appropriate in concept, but not mature enough for a reasonable quality portal. In those cases, a portal can be draftified, but should not be in main portal space. To get it into main portal space, simply improve the topic articles enough to allow a decent quality portal to be made. · · · Peter (Southwood) (talk): 20:15, 23 May 2018 (UTC)
There has to be some compromise between maintaining overall quality of the portal namespace and having pages being worked on. To illustrate, with a single edit I created [1], as an unfinished portal it does not meet the guidelines. To finish it is fairly easy second edit [2]. It is now finished and meets the guidelines. There is little point in draftifying what can be achieved in a single edit. JLJ001 (talk) 20:23, 23 May 2018 (UTC)
In theory, a FA quality article could be created in a single edit. The point is not what could be done in an edit, but what has not been done yet. If an unfinished portal is draftified for being insufficiently complete, the remedy is to complete it, then move it back to portal space. Draftification should be done when there is no apparent improvement occurring over time, the portal is moribund, or when there is talk page consensus that the topic is not currently ready for a portal, but could become ready in the foreseeable future. Where there is no reasonable probability of improvement, a portal may be taken to MfD. To indicate that a portal is under construction, we have a template. · · · Peter (Southwood) (talk): 05:35, 24 May 2018 (UTC)
[ec] The topic should have enough articles that the portal can display a reasonable number of fairly good quality leads, with some substantial content. I would recomment the majority should be B-class or better, or at least meet B-class criteria for the lead.· · · Peter (Southwood) (talk): 19:33, 23 May 2018 (UTC)
An implicit part of "There must be sufficient articles on the topic to make a portal worthwhile" is that this is open to interpretation, partly because other than GA/FA, there is no classification system that can be relied on. Anyone can tag an article as B-class. Equally anyone can come along and say it's really only C-class, and re-tag it. Exactly the same issue applies to the vital article process, the system of creating wikiprojects, and even the number of links in the article. If we were to set any hard number, people could either artificially boost the article to meet the requirements, or deliberately degrade the article prior to trying to delete the portal. In short, there is no substitute to common sense. If an portal is useful, then it's humans that will decide that through consensus, not through grades, numbers or statistics. JLJ001 (talk) 19:49, 23 May 2018 (UTC)
I agree, but some guidance is useful for the clueless. Some are clueless due to lack of experience, and some are just that way. Where opinions differ on interpretation, third opinions and consensus come to the rescue, I use B-class because it is relatively easy to achieve because it does not require outside assistance. Other editors can reassess and come to a consensus for B-class if it is applied inappropriately. B-R-D applies. · · · Peter (Southwood) (talk): 20:00, 23 May 2018 (UTC)
Given that this is not unreasonable, I have added this to the page. JLJ001 (talk) 20:09, 23 May 2018 (UTC)

Such a major (peculiar) refactoring of what constitutes a portal should be much more widely advertised, a notice at every portal and every wikiproject with a portal at the minimum. I tripped over this quite by accident. Espresso Addict (talk) 23:21, 23 May 2018 (UTC)

You are having a laugh right? What next, an advertisement in the window of the local newsagent? It was posted on the talk page of WikiProject Portals; somewhere you keep an eye on if you give two hoots about portals. Cesdeva (talk) 00:43, 24 May 2018 (UTC)
No, I'm not. Very few portal maintainers will be actively watching that page which until recently had been largely dead for years. Espresso Addict (talk) 01:12, 24 May 2018 (UTC)
@Espresso Addict: You mention the issue of content forks. You clearly haven't observed this, but portals now transclude their content directly from articles themselves. This is simply telling people to do that. JLJ001 (talk) 01:00, 24 May 2018 (UTC)
We are clearly talking at cross purposes. I strongly don't think that portals should do that at all, let alone be advised or forced to do it, which seems to be the current proposition. I was extremely disconcerted to find that Portal Cornwall was being reorganised along those lines and flatly furious to find that the person who is doing this proposes to continue to do it across all UK portals.
Where is the discussion where this nonsense was agreed? Espresso Addict (talk) 01:12, 24 May 2018 (UTC)
There was a massive RfC about portals only a few weeks ago, and it was agreed then. And before you go off to the complaints department, please note that this change has been deployed on over a thousand portals so far with generally positive feedback. JLJ001 (talk) 01:34, 24 May 2018 (UTC)
The conclusion of that RfC was "There exists a strong consensus against deleting or even deprecating portals at this time." Espresso Addict (talk) 01:40, 24 May 2018 (UTC)
In no way does that affect the validity of updating portals with these new templates, and insisting they are used wherever practical. JLJ001 (talk) 01:57, 24 May 2018 (UTC)
The RfC also indicated a fairly strong consensus that the moribund state of portals should be addressed.This is part of an attempt to do just that.
The RfC was advertised on every portal main page. Anyone actively maintaining a portal could reasonably be considered to have been notified. Anyone not checking for changes on a portal over about a month cannot reasonably claim to be actively maintaining it.
The wording about content forks should be clarified. Transcluding the lead section or parts thereof is not really a content fork, it is more a mirror, as there is only one original whech can be edited. This makes it less of a content fork than manually summarised content used as a summary section in a related article, which is common practice, and necessary for coherence of a related set of articles. This practice of transclusion reduces actual forking as the portal automatically remains in date with the transcluded article leads.
There is also a need for clarification about red links. Any red link that is transcluded from another article should be considered acceptable if the article from which it is transcluded is appropriate for transclusion. (My suggested criteria of B-class or better would apply here). Red links in a "to do" section would also be appropriate. Which red links are left that would not be allowed, and why not? · · · Peter (Southwood) (talk): 05:21, 24 May 2018 (UTC)
In order to keep the guidelines concise, common-sense interpretations were left out, but it seems some adjustments need making. The word 'generally' could be added in the red links part; I think that would provide reasonable allowance for the legitimate purposes you stated. I'll have a think about how to word the content fork and mirror section less ambiguously. Having red-links in the navigation part would be counter to the function, that's what I was attempting to guard against. I'm hesitant to adjust the current draft, as it would change the proposal mid-rfc, but if a draft 2.0 happens I'll be sure to make sure your points are addressed. Kind regards, Cesdeva (talk) 09:52, 24 May 2018 (UTC)

Main issues

  • The feedback on this has been very useful, but we do need to act on it so I will try an summarise the main points so far:
    • Red Links. It seems to be generally thought that portals should contain redlinks to article titles.
    • Portal title. It has been pointed out that in some situations the portal title does not match the main article, eg. Portal:Australian cars -> Automotive industry in Australia.
    • Content forks. This idea could be revisited and further clarified.
    • It should not be a requirement to use the new Transclude templates, but this guideline does suggest it is.
    • The process for dealing with unfinished portals needs adjustment.
    • neither the inclusion or content guidelines are sufficiently detailed.
Anyone that wants to help reworking the draft guidelines is welcome. We will work on it to address the main issues put forward here. However it is clear the RfC will need to be started anew once these issues have been addressed. JLJ001 (talk) 08:46, 24 May 2018 (UTC)
I am not ignoring the issue of the MOS, but I don't think it will be decided here, that would probably be a MOS issue to be decided at the MOS page. For those interested it's being discussed at Wikipedia talk:WikiProject Portals#To what extent does the MOS apply to portals?. JLJ001 (talk) 08:53, 24 May 2018 (UTC)
Good plan. A lot of potentially useful comment has come up here. I am going to think about when and where a portal is worth having a bit more, based on my comments about levels of linking above. I will look at a few outlines and see if the idea looks workable in practice. · · · Peter (Southwood) (talk): 12:21, 24 May 2018 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Discussion at Wikipedia talk:Manual of Style/Portals#RfC: Adopt as a MoS guideline

 You are invited to join the discussion at Wikipedia talk:Manual of Style/Portals#RfC: Adopt as a MoS guideline . - Evad37 [talk] 03:00, 31 May 2018 (UTC)

Discussion at Wikipedia talk:WikiProject Portals § Time for some portal creation criteria?

 You are invited to join the discussion at Wikipedia talk:WikiProject Portals § Time for some portal creation criteria?. North America1000 22:36, 5 October 2018 (UTC)

Current version of the guidelines

The current version of the guidelines does not have consensus. The page should be reverted back, and the proposed version saved to a subpage until a new RFC is opened. – Lionel(talk) 07:52, 6 June 2018 (UTC)

I have just reverted[3] back to the the version of 2 May 2016, which was unchanged for two years until 23 May 2018, when it was almost entirely rewritten[4] by The Transhumanist.
In particular, TTH removed the second para which reads "Please bear in mind that portals should be about broad subject areas, which are likely to attract large numbers of interested readers and portal maintainers".
No evidence has been offered of a broad community consensus to change the purpose of an entire namespace. That would require an RFC. --BrownHairedGirl (talk) • (contribs) 23:55, 27 September 2018 (UTC)
The purpose of the portal namespace was changed long ago, by the very people who have built portals, from the moment that statement was written. Editors build portals on the subjects that interest them (the same as with articles), rather than on the traffic prospects of a subject, and except for the few portals listed on the Main Page, always have. This practice is therefore very well established. (See WP:PGCHANGE).
In addition to this, the lead statement itself is in error, as portals by their very nature do not attract large numbers of interested readers or portal maintainers. That's because portal titles generally do not show up in external searches of their subject names, which is where large numbers of readers to pages come from. For example, "Portal:Fish" doesn't come up when you search for "Fish". An external search will show a portal if the word "portal" is included in the search term, but googlers don't typically enter that term. Portals primarily receive internal traffic from within Wikipedia itself, via the internal links that readers click on. They always have.
And while "broad" isn't defined in the lead, guidance for the scope of portals is provided further down the page, where it states the number of articles to be included to be "about 20", a guideline that has been in place since May 2009.    — The Transhumanist   18:22, 5 October 2018 (UTC)
While we're on the subject of revising the guidelines, let us not forget the other version we once proposed above still exists. Perhaps some of the ideas there could be useful as well. — AfroThundr (u · t · c) 04:29, 6 October 2018 (UTC)

Concerning portal guidelines and topic minimums

The old portal guideline that has been restored has something that the new version did not: a number.

It sets the minimum number of articles to be included in a portal's coverage to be "about 20".

It's in the Article selection section.

So, when people refer to the minimum number of articles required to support a portal, that's where the formal minimum has been recorded since May 2009. Prior to that, it was set at "about 30".

In practice, portal developers often never reached the "about 20" subpage mark for selected articles, and so the actual scope of coverage for the set of (old-style) portals that existed at the time of the RfC in April 2018 ranges from 1 selected article on up. That's why the new version didn't include a number.

But, the "about 20" is the current standard by which portals are measured at MfD, and represents the current consensus of the low bar for portals.

In order for that to be changed a new consensus would need to be established to replace it, which seems unlikely, in view of the results of the RfC last April, where editors decided by a margin of 2 to 1 in favor of keeping portals.

I hope you've found the above explanation informative and helpful. Sincerely,    — The Transhumanist   21:19, 6 October 2018 (UTC)

Note also that the old-style of portals, that use subpages, is still a valid approach. Creating those subpages is quite a chore, and often never reaches the "about 20" threshold. Most of them have fewer than that, which has become the common practice. Even Portal:Mathematics, one of the highest-traffic portals which is presented on the Main Page, only has about 40.    — The Transhumanist   18:55, 5 November 2018 (UTC)

Concerning the inclusion of "Selected article(s)" section

The "Required" section does not currently specify "selected articles". This should probably be corrected, so I will add something which can be amended if anyone has a better way to say it. · · · Peter (Southwood) (talk): 05:47, 7 November 2018 (UTC)

There are a growing number of portals that don't have a section titled "Selected articles", but that still have sections with other titles that transclude article excerpts. It's the inclusion of prose on a subject that we want to focus on here, which is already covered by at least one policy. Wikipedia:Criteria for speedy deletion#P2. Underpopulated portal states:

Any portal based on a topic for which there is only a stub header article or fewer than three non-stub articles detailing subject matter that would be appropriate to present under the title of that portal.

This also means that subject matter (excerpts) are required, and any portal that lacks such can be speedy deleted. Subject matter should therefore be covered in the "Required" section of the guideline. But without requiring any specific wording of its section heading(s).    — The Transhumanist   06:38, 7 November 2018 (UTC)

Agreed, the section title is not the point, but "selected article" is convenient to cover biographies and general topics, as opposed to "In the news", "Did you know", images and suchlike optional extras · · · Peter (Southwood) (talk): 06:48, 7 November 2018 (UTC)
Maybe we should either link P2 or transclude it in the guideline for easy reference? · · · Peter (Southwood) (talk): 06:52, 7 November 2018 (UTC)
Good ideas. I favor transclusion, as it will update automatically. A preference I've acquired from the new design of portals. :)    — The Transhumanist   07:02, 7 November 2018 (UTC)
I also prefer transclusion, because it is right there and harder to miss. · · · Peter (Southwood) (talk): 15:41, 7 November 2018 (UTC)

1. The second item from "Recommended" describes practice which is not generally used, is incompatible with the automation tools, and should be updated. · · · Peter (Southwood) (talk): 06:01, 7 November 2018 (UTC)

@Pbsouthwood: If the second item changes, nobody who reads your post above in the future will know what you were referring to. ;) I'm not sure I do now. :)    — The Transhumanist   06:44, 7 November 2018 (UTC)
Good point, my train of thought was derailed by an edit conflict. I will clarify by a quote:
Selected article – The first instance of the article title should link to the full article. Images should not use thumbnail formatting unless the background color of the portal content is specified as "transparent" (typically in the box-header subpage). Keep images small; 100px (as on the Main Page) is best. Remember that in compliance with WP:NFCC, non-free images cannot be used outside of articles.
(my emphasis, identifying the part that needs revision.) Why not thumbnail, what is the relevance of transparent, and why 100px?· · · Peter (Southwood) (talk): 07:00, 7 November 2018 (UTC)
Image placement is by and large automated. I'd remove that (emphasized) passage altogether. The first sentence should go too, unless the transclusion software is modified to linkify the first instance of the article title. Currently, many of the excerpts don't linkify the first instance, because they are are not linkified in the article leads transcluded.    — The Transhumanist   07:10, 7 November 2018 (UTC)
Just so. All we would be left with is the bit about non-free images. Read more (or preferred equivalent) gets one to the actual article adequately. · · · Peter (Southwood) (talk): 07:15, 7 November 2018 (UTC)
I will strike through pending a decision. · · · Peter (Southwood) (talk): 15:44, 7 November 2018 (UTC)
I think that the bolded part in the statement above is not what is happening (and potentially not what was happening before automation was even a thing: I've seen tiny images and huge images commonly through upgrading and maintenance). I think that it should be removed (as well as the thumbnail formatting). Dreamy Jazz 🎷 talk to me | my contributions 12:15, 11 December 2018 (UTC)

2. The recommendations for Selected picture are similarly out of date. The caption requirement may be difficult with the current templates. Not sure how to reword this one. The intention of a useful caption is good, but can it be done? There are so many strange image formats that might have to be parsed that it could get too expensive. Might be better in extreme cases to just go fix the page. Any suggestions? · · · Peter (Southwood) (talk): 16:00, 7 November 2018 (UTC)

We of course want to avoid making the Lua modules too bloated. Is there a way to make a module conditionally call another submodule to reduce the base run time? We could export the more exotic template/image parsing that way, and only use it when necessary. If that works, we can add all the extra logic we need, and only call it on the problem pages. — AfroThundr (u · t · c) 17:38, 7 November 2018 (UTC)

3. Sections "Recommended" and "Optional" are both optional, and to some extent both recommended. Should they be combined? · · · Peter (Southwood) (talk): 16:18, 7 November 2018 (UTC)

"Recommended" has a stronger impetus for inclusion than "Optional" (also works as "Suggested"). I think they would be better as separate sections, but some of the items might need to move. — AfroThundr (u · t · c) 17:38, 7 November 2018 (UTC)
Is that a suggestion or a recommendation? ;-) Definitely an option... · · · Peter (Southwood) (talk): 11:07, 9 November 2018 (UTC)

Second sentence contradicts WP:NOTCOMPULSORY policy, and should be removed

From the lead, I removed "Do not create a portal if you do not intend to assist in its regular maintenance" , as it violates the policy WP:NOTCOMPULSORY, which states: "Wikipedia is a volunteer community and does not require the Wikipedians to give any more time and effort than they wish. Focus on improving the encyclopedia itself, rather than demanding more from other Wikipedians. Editors are free to take a break or leave Wikipedia at any time. " See also Wikipedia:Wikipedia is a volunteer service.

The new portal designs are automated, so that portals keep themselves updated almost fully automatically, taking advantage of edits made to the encyclopedia itself. WikiProject participants handle other maintenance that arise. Regular maintainers are no longer needed, and never materialized anyways. The lack of maintainers is why the portal system overhaul is taking place. And according to the WP:NOTCOMPULSORY policy, we can't compel or require editors to work any harder on a page than they are willing to provide at any given moment.

Someone reverted the removal, but, as the sentence is in error because it contradicts policy, someone should go onto the page and directly remove it.    — The Transhumanist   05:04, 7 November 2018 (UTC)

I agree that the current wording is inappropriate, but could be modified to advice not to waste one's efforts, as an out of date portal is at risk of nomination for deletion.
Something like:
Portals which require manual updating are at a greater risk of nomination for deletion if they are not kept up to date. Do not expect other editors to maintain a portal you create. To avoid this problem portals can be created that automatically update. · · · Peter (Southwood) (talk): 05:30, 7 November 2018 (UTC)
@Pbsouthwood: Nice. This reflects the current state of affairs for portals. Perhaps change "Portals which require manual updating" to "Manually maintained portals".    — The Transhumanist   06:13, 7 November 2018 (UTC)
  • I oppose this change, because its main purpose seems to me to legitimate the bad practice of the proposer, @The Transhumanist (TTH). The same editor has also been the most prolific creator of portals of in recent months, so the change seems to be mostly about personal benefit.
The problem comes in two parts:
  1. The Transhumanist's drive-by creation of portals, sometimes as rapidly as one per minute. The result is portals which are created with basic errors, and then abandoned.
  2. The need for ongoing maintenance has been massively reduced, but not eliminated.
As an example of the problems caused by drive-by creation, I note Portal:Fresno, which I just discovered. It is categorised in Category:Fresno, which is a disambiguation category; it should be in Category:Fresno, California. That is just a variant of the problems which drew my attention to portals in September, when TTH had created dozens of portals whose only category was a non-existent one which then showed in Special:WantedCategories.
In those cases, TTH's sloppiness extend to not even glancing at the bottom of the page to see the category list consisted of a redlink. In the case of Portal:Fresno, the category is blue, but no page should be in it, because it is a disambiguation category. I have just spent five minutes trying to figure out how to correct the category, but it seems to be generated by some some obscure template, so 9 weeks after its creation it remains unfixed.
The same lack of basic care which led TTH to drive on by without even checking whether the portal was in any valid category also led to the categorytree display being broken, because it too was linked to Category:Fresno rather than Category:Fresno, California. I fixed that[5], but the categorisation of the portal remains broken. It isn't even in any subset of Category:Portals, e.g. Category:California portals and Category:United States portals by city. So anyone trying to monitor or maintain portals won't find this one.
These problems with TTH's drive-by-creations are widespread: it is a mass creation of messes for others to tidy up, and here TTH wants to change the guidance to rubber-stamp that bad practice.
Secondly, the need for portal maintenance has been reduced, but not eliminated. Despite the fix I did to the category display, Portal:Fresno does not show up in Special:WhatLinksHere/Category:Fresno, California. So if the category is renamed, there is no way for those implementing the move to detect that the portal needs updating. (The lengthy thread on my talk at User talk:BrownHairedGirl#Linking_to_portals_under_construction (permalink) is mostly about these problems.
So ongoing maintenance is still needed. It has been reduced by technical changes, but not eliminated. I have identified one area which needs ongoing attention, but here may be more ... and given TTH's long pattern of sloppiness in basic tasks of portal creation, I place no weight on their assurances that there isn't much else to check.
The guidance should therefore stay. And instead of trying to change guidelines, TTH should concentrate on cleaning up the mess created by TTH's drive-by-creation sprees. --BrownHairedGirl (talk) • (contribs) 16:39, 11 November 2018 (UTC)
PS note that POrtal:Fresno has only one reader-facing incoming link, from Category:Fresno . As note above, that is dabcat, so readers should never see it; no portal link should be in that page, and it was added[6] in an AWB by TTH who neglected WP:AWBRULES #1: "You are responsible for every edit made. Do not sacrifice quality for speed, and review all changes before saving". The result is that after 9 weeks, the portal is completely unsignposted to readers, which is why it has had only 49 pageviews in 64 days (all presumably by editors).
Part of the maintenance needed is ensuring that the portal is adequately signposted. TTH has neither done that directly, nor made any efort to avertise the pprtal in project space to notify others of the needs for links. (I checked: no links to it from Wikipedia-space[7] or Wikipedia talk[8]). --BrownHairedGirl (talk) • (contribs) 16:52, 11 November 2018 (UTC)
  • Some data.
I just used Petscan to check for portals in disambiguation categories, and found 5 of them:
Note that:
  1. All but the last (Portal:Rio de Janeiro) was created by @The Transhumanist, and TTH is the only other editor of that page.
  2. All of them has a broken categorytree,[9] except for Portal:Fresno, which I fixed.
  3. Three of them Portal:Transformers, Portal:Fresno, & Portal:Woodstock) has only one incoming link from a category or article ... and in each case it is the dismabiguation cat which shouldn't even be linked there.
  4. Only one these portals has a 60-day pageview total of even one view per day: (note the numbers are as of now, but will increase as a result of posting the links here)
  5. These five portals have between them a total of only 4 incoming links from articles: 2 each to Portal:Santiago and Portal:Santiago.
These pages were all created between 26 July 2018‎ and 8 September 2018, so they are between 9 and 14 weeks old. They need maintenance, but instead in all but one case only their creator has edited them (until I edited Fresno today). So these portals do rely on the creator to maintain them ... but instead of doing that maintenance, their creator is trying to change the rules to dump the cleanup task onto others.
And all this for pages which readers do not read. --BrownHairedGirl (talk) • (contribs)
Thank you, BrownHairedGirl, for reporting the disambiguation problem on these 5 portals. I wasn't even aware of such a problem to look for, let alone how to look for it. Now that I do, I will happily use the PetScan procedure that you provided to monitor for such instances in the future. Again, thank you. ;)
Now, getting back to the disambiguation thing...
Portal:Rio de Janeiro  Done
Portal:Woodstock  Done
Portal:Transformers  Done
Portal:Santiago (disambiguated)  Done
Portal:Fresno, California (renamed)  Done
I am highly impressed with your application of PetScan. That thing is an incredible filter. Out of all the portals I created, it found the 4 with that problem (and 1 by someone else). Nice. If there are any other useful PetScan queries you can provide to help detect portal errors to improve quality assurance, please don't hesitate to do so.
By the way, thank you for the heads up on the red categories. I generally leave redlinks in place for them to turn blue via wikimagic, but removed the categorization links that you pointed out were causing problems.
Regarding the maintenance clause, I am concerned that it would deter new or less experienced editors from creating individual portals they are considering making. Because they may not know that Wikipedia is not compulsory. Having an erroneous damper on portal creation in the portal guideline seems counter productive. The guideline should encourage, not mistakenly discourage, portal creation.
Sincerely,    — The Transhumanist   09:56, 26 December 2018 (UTC)
My own preference is that people do not make unnecessary work for others on Wikipedia, but as pointed out above, editing Wikipedia is a voluntary activity and we are are urged to accept good faith edits in the spirit in which they are made, and to assume good faith in the absence of evidence to the contrary. When we find this unbearably tedious we can find somewhere else to do something useful. While the malformed portals are aesthetically unsatisfactory, and may be functionally deficient, I am not convinced that they are actually harmful. There is an argument that by producing larger numbers the bugs will be exposed more effectively, but once a recurring issue has been identified it should be fixed before continuing with creating similar portals with similar faults. Considering the speed and ease of creating a new portal, it would not be unreasonable to expect the creator to apply reasonable diligence to checking for defects, and if there are defects, either self-discovered, or later reported, either fix them, delete the broken portal as a precautionary procedure, or mark it as an example of a problem that is actively being investigated and considered potentially fixable within a reasonable time frame.
Thanks for finding the portals in disambiguation categories. I agree they should not exist. Now that we know they are being created and not noticed at the time, we can look into countermeasures. The first step would be to find out why were they not noticed by the creator, then we can specify what to look out for, or write it into the relevant template.
The point to this particular item is how do we reword the guidance so that it both complies with the spirit of voluntary work, and provides a remedy when the same errors are repeated.· · · Peter (Southwood) (talk): 17:43, 16 November 2018 (UTC)


Poll on this change

Because this change could be controversial, if you want to support or oppose this change, please do so below:

IMPLEMENTED
Implemented by The Transhumanist. Closing on their behalf. Dreamy Jazz 🎷 talk to me | my contributions 23:23, 28 November 2018 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Concerning section: Article selection

1. This refers primarily to the selected article display which I have added to the "Required" section. Should we move this into the "Required" section as a subsection for direct ease of reference? · · · Peter (Southwood) (talk): 06:31, 7 November 2018 (UTC)

2. The number of selected content items is suggested as 20, as a rough guide. do we interpret this as the sum of biographies and other articles, which may be displayed in seperate boxes, or as the recommendation as a minimum for each display box, or something else? The current automation system does not easily seperate biographies from other articles when using a navbox as a structural template. I would prefer to be allowed to have additional selected items when they have fewer than 20 available components, as long as the main one is sufficient. · · · Peter (Southwood) (talk): 06:31, 7 November 2018 (UTC)

  • As a sum. That is the minimum number of articles a portal should have, when being considered for deletion at MfD. We need to be careful that we don't let that threshold get obscured or lost due to a rewrite.    — The Transhumanist   06:59, 7 November 2018 (UTC)
    • I agree that it should be a sum of excerpts from ordinary topical articles and biographies, excluding images and other optional material. The sum of 20 is currently a recommendation rather than a hard limit, and I think that should stand to allow for special cases, where we should let the circumstances be considered. In other words, if there are not 20 available for a good reason, motivate with good reasons why the portal is worthwhile and allow consensus to decide, preferably before creating the portal. · · · Peter (Southwood) (talk): 07:09, 7 November 2018 (UTC)

3. The quality of selected articles as described in this section in not currently checked by the automation systems. In fact as far as I know exactly none of these criteria are checked. Do we try to set some quality criteria for selected articles, and if so, what is reasonably practicable? · · · Peter (Southwood) (talk): 17:03, 7 November 2018 (UTC)

This sort of feeds off of my comment above about submodules in Lua, as I imagine this would be kind of expensive. We could add some thresholds to require a certain number of C-class articles or above (like 10, maybe?), and display an edit warning if it is not met. This would of course not prevent a page from being published anyway, ignoring the warning. We could also add a tracking category for that, which would retroactively allow us to find all the ones that don't currently meet this criteria, after it is added. — AfroThundr (u · t · c) 17:47, 7 November 2018 (UTC)
What we have currently in place is a stub filter. Stubs are automatically skipped over by the lua module, and are not displayed in Selected articles sections. I do not support raising that threshold, because we are talking about information dispersal. Having summaries of topics is half the point of portals, which is thwarted if we hide most of them because their article bodies are not complete. Portals are lead browsing tools. Besides, we want to drive traffic to all articles, so that more people will work on them. If you hide them, you are saving the work for our already overburdened regular editors.    — The Transhumanist   02:41, 9 November 2018 (UTC)
Portals are lead browsing tools. They are. Probably should be. So should we not transclude the whole lead as standard practice? A lot of our leads are pretty shabby, but in some cases the whole lead is quite a bit more useful than just one or two paragraphs, and where the whole lead is too long, we may get people fixing it. · · · Peter (Southwood) (talk): 11:14, 9 November 2018 (UTC)
@Pbsouthwood: That's what the Read more links are for.    — The Transhumanist   10:44, 26 December 2018 (UTC)
The Transhumanist, The Read more links are to get to the whole article, not just the lead. I don't think that we should provide excepts that are deliberately stunted when it takes no more effort to provide the whole lead. A well written lead is a coherent unit, that does not gain by being arbitrarily pruned. Or is this a problem with processing time? Anyway, I would be interested to see other opinions on this. · · · Peter (Southwood) (talk): 17:42, 26 December 2018 (UTC)
Also, this could be another one of the checks we could hypothetically do via userscript (re: portal tool). — AfroThundr (u · t · c) 17:53, 7 November 2018 (UTC)
This would be most useful when looking for subjects with enough information to support portal creation. Currently, what I need is a script to analyze navbox templates, for example, to count how many non-stub articles are listed on them. What I've been doing so far is creating portals in preview mode, and then clicking on the slideshow arrows to count how many articles are displayed in the Selected general articles section. That is both tedious and time-consuming. And if you forget the name of the article you started on, you may count right past it when it comes up again, and you have to start all over again. "497, 498, 499, 500. Wait a sec, I'm pretty sure there weren't 500 articles on the template!" :) With an automated tool, you could have it add such templates to a list, then change their namespace prefixes to "Portal:" and use the list for portal creation. We can avoid having underpopulated portals by never building underpopulated portals in the first place. Auto-tools could sure help with that.    — The Transhumanist   02:41, 9 November 2018 (UTC)
Could a bot periodically work through navboxes and leave normally invisible pointers indicating current article quality? This would allow only articles above a given bar to be selected. · · · Peter (Southwood) (talk): 11:19, 9 November 2018 (UTC)
@Pbsouthwood: The articles aren't so much selected, as simply displayed. For example, if you use "Template:X", all the topics on there, except stubs, get displayed on "Portal:X". It is handled by the underlying Lua modules. It is not clear what you envision the bot would do.    — The Transhumanist   12:05, 9 November 2018 (UTC)
The article displayed is randomly selected from all articles in Template:X, clicking through lets you display all the other {non-stub?) articles. If it were possible to select articles by quality class, there could be a set of selected article boxes for the different classes, or a box displaying only the better quality articles. · · · Peter (Southwood) (talk): 09:04, 10 November 2018 (UTC)
@Pbsouthwood: Not all of the articles. A maximum of 50 are displayed. Some templates have over 50 articles, and you can specify more than one sourcepage for the Selected articles section, which may add up to hundreds or more articles between them. You can also specify other page types besides navigation templates, like lists. The Selected historical figures section of Portal:History pulls its entries from the page Wikipedia:Vital articles/Level/4/People, which includes a few shy of 2,000 entries. You can also specify sections. One of my favorite techniques is to specify a section of the portal itself, such its Recognized content section. That is the only way I know of so far of selecting articles by quality class.    — The Transhumanist   10:58, 26 December 2018 (UTC)
The Transhumanist, Ok, maximum of 50. Randomly chosen? If so, would it not be better to showcase the content by displaying 50 of the better quality articles when random 50 could display a large proportion of stubs and starts? A counterargument is that random gives them all fair exposure, so it is a bit of an interpretation of portal function problem. Is quality or breadth more important?
How many of the new portals actually have a Recognised content section? Is there a way to identify them from those which do not? It might be a useful maintenance category. · · · Peter (Southwood) (talk): 17:55, 26 December 2018 (UTC)
Also related to the portal tool, we could use it to help with redcat detection on portal creation. This would solve those red categories and category trees, as was mentioned by BHG above. We should also take more time to QC them as they are created. — AfroThundr (u · t · c) 17:21, 13 November 2018 (UTC)
This query lists the redcats in portal namespace. Certes (talk) 18:41, 13 November 2018 (UTC)
Cute icon.    — The Transhumanist   11:00, 26 December 2018 (UTC)

Concerning the inclusion of "Related portals" section

I have boldly removed a requirement for an item which does not have to exist. It was reasonable when the header was "strongly recommended", but that was changed to "required", and subportals and related portals cannot be required as they are external to the portal. If anyone disagrees, feel free to revert with motivation. · · · Peter (Southwood) (talk): 05:30, 7 November 2018 (UTC)
I agree with your moving of the related portals feature to Wikipedia:Portal_guidelines#Recommended. We don't have any way currently to automate the maintenance of related portals sections, and so those should definitely not be required, as they would naturally grow stale and out-of-date and detract from portal quality as a whole.    — The Transhumanist   06:03, 7 November 2018 (UTC)
Not having the tools is not necessarily a valid argument, just a convenient one. However, the existance of a portal should not be conditional on the existence of other portals - a chicken and egg situation. We can, and probably should, look into the possibility of automating related portal links, possibly through an extension of navbox content. (just brainstorming here as navboxes are so convenient). · · · Peter (Southwood) (talk): 06:42, 7 November 2018 (UTC)
On another note, there are plenty of other pathways to portals, that they don't necessarily need a system of interconnections between them. Drawing traffic from outside the portal system is what we should be focusing on: the placement of links to each portal.    — The Transhumanist   06:50, 7 November 2018 (UTC)
Agreed. Subportals are more useful to link than other related portals, as they cover subsets of the topic when the topic is too big for a monolithic portal. · · · Peter (Southwood) (talk): 07:22, 7 November 2018 (UTC)
I disagree with this change. Our primary aim is to have quality portals, not automated portals. Automation may help with quality to certain extent, but we're not going to sacrifice the rest because it can't be automated. Related portals has been a required item for more than a decade so that's where the consensus is at. The automation phase in contrast is fairly new and it shouldn't be allowed to rewrite the rules just because the computer says no. – Finnusertop (talk ⋅ contribs) 12:32, 9 December 2018 (UTC)
I agree with Finnusertop - let's not get so enthusiastic about the automation process that we discard useful features - related portals are useful, and we shouldn't be discarding them because they can't be automated (yet). Simon Burchell (talk) 13:28, 10 December 2018 (UTC)
I agree with Finnusertop. Just because the Computer says no (at the moment), shouldn't mean we remove the requirement. Manual addition should be easy with looking at Portal:Portals. Dreamy Jazz 🎷 talk to me | my contributions 13:41, 10 December 2018 (UTC)
@Finnusertop, Simon Burchell, and Dreamy Jazz:. I would like to point out that the text before my change 'required' links to subportals or related portals. It is quite obvious that some portals will not have sub-portals, so it would be unreasonable to require links to them. The consequence of requiring links to subportals would be that all portals without subportals would be eligible for deletion. Once deleted, the portals for which they were the only subportals would also be eligible for deletion. Apply recursively and there will be no portals at all.
The situation with related portals is less dire. It is possible that for almost any portal, another portal can be found, or if necessary, created, which could be considered a related portal. However, how does one decide which portals are related to any given portal? Without some guidance this is likely to lead to endless squabbling over technicalities, as this could be used as a tool to attempt to delete portals on the grounds that there are no sufficiently related portals and it is a requirement that such portals exist so they can be linked.
Also, who would be responsible for finding at least one sufficiently related portal and linking to it? Logically, as a requirement, this would be the portal creator.
If I remember correctly the original guidance was strongly recommended, and was changed to required recently, I am less concerned with history than with getting a workable guidance document, but if anyone wants to track down who did what and when, go ahead. If we want to rely on a previous consensus, we should be clear on what it actually was, and that it is still relevant. It might also be relevant to check through the old style portals to find out if this "requirement" was universally complied with. If not, it is indicative that the claimed previous consensus was not strictly applied as a requirement, and would be more appropriate as a recommendation.
I put it to those who wish to retain the previous wording that they could help by defining a related portal so we can see if it is reasonably practicable to require the presence of a link to one or more in every portal. · · · Peter (Southwood) (talk): 05:49, 11 December 2018 (UTC)
On reflection, I agree with Pbsouthwood in that portals may not always have related portals and that making this required might just be used as a way to delete portals, which meet all the other requirements. I think, however, the related portals section should still be encouraged or required when there are portals which would be appropriate to link to. This could be a bit of a grey area, so what I mean by appropriate links are portals which have shared content, such as articles. The amount of articles/content needed to make a link could be a grey area. I would suggest something like 3, but some portals which warrant a link may only have 1 article shared between them (e.g. Portal:Northumberland and Portal:Morpeth, Northumberland are only connected by the Morpeth, Northumberland article, but Morpeth is the county town and market town of Northumberland), so I would suggest that the amount of shared articles be a recommended minimum of 3, but editors can use their own discretion with the amount links needed (within reason). Furthermore, I would suggest an absolute minimum of 1 article/piece of content to connect the portals to prevent editors spamming links to a portal which has no connection; If a connection exists, but no articles/content link the portals currently, it should be created first. Dreamy Jazz 🎷 talk to me | my contributions 10:06, 11 December 2018 (UTC)
I would argue that a sub-portal relationship is a clear indication of related portals - both ways. So Portal:Northumberland and Portal:Morpeth, Northumberland would be clearly related in that one topic is part of the other. In this case the main point of having Portal:Northumberland and Portal:Morpeth, Northumberland is so that there is less need for overlapping content. One common article (Morpeth, Northumberland) could quite easily be both necessary and sufficient in such a case. The grey areas are the tricky ones. For example, Portal:Underwater diving has related portal links to Portal:Medicine, Portal:Technology, Portal:Water sports, Portal:Physics, Portal:Occupational safety and health and Portal:Marine life. I can probably think of a dozen more possibilities without straining myself, but where do I stop? Am I going too far? Is marine life really relevant? What about physiology, archaeology, law, employment, education, petroleum extraction, construction, welding? Some of these are getting really tenuous, but the connections exist. Conversely, the first portal had no related portals at all, and the second portal could have been in a rather different topic area, making two unrelated portals. We now have a lot of portals, but to be sure of having related portals to link in all cases it may be necessary to create even more. Depends on how closely related they should be. This is a bit of a minefield in my opinion. Making them optional but recommended seems more prudent. The other way of looking at it is that Portal:Contents is related to every portal in Wikipedia, making the requirement somewhat trivial. Cheers, · · · Peter (Southwood) (talk): 10:57, 11 December 2018 (UTC)
Another good reason to think about what makes portals related, it that it is the first step towards automating the inclusion of related portal links. If that is possible. · · · Peter (Southwood) (talk): 11:17, 11 December 2018 (UTC)
It seems that the best idea is that it should be left to editor discretion on what a portal is linked to. I think common sense with some discussions here and there are better than trying to think up of criteria for linking a portal. Dreamy Jazz 🎷 talk to me | my contributions 12:09, 11 December 2018 (UTC)
Some guidance would be useful, but it should be flexible enough to deal with unexpected cases. · · · Peter (Southwood) (talk): 12:15, 11 December 2018 (UTC)
@Pbsouthwood: Do you have any ideas? I am out of ideas. Dreamy Jazz 🎷 talk to me | my contributions 12:27, 11 December 2018 (UTC)
Dreamy Jazz, As I mention somewhere else, I think that subportals one level down and superportals (for want of a better term) one level up should be linked where known (it is not always obvious). Other related portals are to some extent the opinion of the reader, like the list I mentioned above. I think in those cases just BRD, on a similar principle to including an article in the scope of a WikiProject. If someone can provide a reasonable rationale, then allow the link. I guess it would be possible to go too far, anything that is possible will probably happen some time, but I don't expect it to happen much. Who knows? Like everything else on Wikipedia, things can change, and the creator of a portal should be expected to do due diligence, not an exhaustive analysis, so if they leave something non-obvious out, not to get too excited about it. Question becomes how much diligence is due? Just brainstorming, so if something I mention looks daft, let me know. · · · Peter (Southwood) (talk): 14:01, 12 December 2018 (UTC)
Also maybe Finnusertop has some ideas? · · · Peter (Southwood) (talk): 14:05, 12 December 2018 (UTC)
I don't think it's difficult to locate related portals. Even back in the old manually compiled portals system, portals had loads of related portals linked. That should be even easier now when we have so much more portals. Related portals are immensely helpful for readers. That way the Portal namespace becomes an entire navigable web of portals instead of just links you stumble upon on random articles. It's simply a question of who will add them. In the old days it was the person who created the portal, since it's only reasonable to include required items when creating one (and they were required already a decade years ago, I checked; "strongly recommended" was a short-lived verbiage that was quickly reverted; it's needless to say that "if there are any" means what it says and it's not an absolute requirement). The downside of the automation phase is that no one is expected to maintain portals, so this task has been relegated to the proverbial someone else. I think we need to combine the best aspects of automation and manual maintenance to really make portals useful. – Finnusertop (talk ⋅ contribs) 17:27, 12 December 2018 (UTC)
Finnusertop, Good point about the "someone else", but how do we encourage portal creators to do the job properly and not pass the buck, while taking into account that we are all volunteers?
I guess deciding which portals are sufficiently related is a BRD and talk page discussion item, as it is unlikely that any simple rule will cover all cases. · · · Peter (Southwood) (talk): 17:28, 26 December 2018 (UTC)

@Pbsouthwood, Finnusertop, and The Transhumanist: Just thought of a way to automate this section. We could convert the portal contents page to a lua module in a similar way to Module:Portal does it, but split the data based on the categories that already exist on the portal contents page. Then the module data could be used by some other module to determine related portals, using parameters provided to the template/module or based on the name of the portal (how we determine what is related needs discussion). The advantages of this are:

  • This would automate and keep updated the related portals section (so would eliminate redlinked portals being kept in the section and allow more relevant portals to be shown later down the line)
  • Portals added to the module would only be completed and working portals, because the contents page only contains completed and working portals
  • The contents page would potentially easier to maintain (only needing to add or remove one line of lua code, instead of working out how the slightly complicated structure of the contents page works and then adding/removing a portal)
  • Could ensure that redlinked portals never show on the contents page (however, this may be expensive, as the current way to do this is a expensive lua function)

However:

  • Certain customisations of the portal contents page may be difficult or impracticable to implement (although from what I can see from the portal contents page the page seems very uniform)
  • Mistakes in the lua code would cause problems for the entire contents page and related portal sections, so some level of protection, possibly advanced levels (such as template editor), would be needed to ensure that mistakes in lua code are rare or non-existent. (I do know that by submitting an edit on a lua module the code is checked for syntax errors, but the errors I am referring to are those which wouldn't be caught such as removing data/functions which could remove portals from the contents page/break the page and cause problems with an automated related portals section).

Of course, such a module would add to the total lua time / lua memory for a given page, but for most portals the time for lua execution is 1.773 seconds (taken Portal:Northumberland as the example here) out of a possible 10 seconds and a small increase in this time won't matter much. What are your thoughts? Dreamy Jazz 🎷 talk to me | my contributions 19:27, 26 December 2018 (UTC)

@Dreamy Jazz: I just noticed your comment. This is a cool idea. It would require extensive testing and probably benchmarking and a pilot before implementation though, to ensure it's well polished. We could gauge how it will perform on a random selection of portals, then tweak as necessary. This is likely the only sane solution to handle organization for the portal namespace moving forward, since the numbers aren't going to shrink. — AfroThundr (u · t · c) 20:26, 11 January 2019 (UTC)

Portals on "Subject bar" template

Greetings, Wondering if guidelines should include mention of Portal placement on "{{Subject bar}}" template? And maybe an example or two?

On many articles I've been adding {{Subject bar |portal1= Biography |portal2= Catholicism |portal3= Italy}} for example. For placement of this template, I remember "S A D" = Subject bar, Authority control, DEFAULTSORT lines in that sequence.

Also, there is a bug in "Authority control" that causes it to not showup. Often (but not always) just removing the blank line before & after Auth.control causes it to magically appear. And changing the initial "a" to A.

Regards, JoeHebda (talk) 13:41, 15 January 2019 (UTC)

JoeHebda, I have no particularly strong opinions on which template is best for portal linkage and where they should go, but I guess that anything that is accepted usage can legitimately be mentioned and a link to the relevant guidance provided. It is probably better to mention and link all accepted methods, formats and locations, so that people are less likely to edit war over them. What would you suggest?· · · Peter Southwood (talk): 19:17, 15 January 2019 (UTC)
Pbsouthwood just a suggestion. Perhaps this can be included in the "Linking to portals" proposed above. Dreamy Jazz 🎷 talk to me | my contributions 22:17, 15 January 2019 (UTC)
Dreamy Jazz, That would be the obvious place to put it, since that is what it is. It is just a matter of what all there is that we should put there to be reasonably complete without going into excessive detail. Until fairly recently I was not even aware that {{Subject bar}} exists There may be other information that should be included that I still don't know about. It is probably better to sketch out the additions on this page until they stabilise, then add to the guidance to avoid potential complaints of lack of consensus later. It would be nice if a few proposals came from people outside the core group.
There are quite a few ways to link to portals. In some ways this is good, but in one way not so good. It makes it more confusing to the reader when there are too many options in too many places. This steepens the learning curve. Ideally there would be just enough methods to deal with all circumstances effectively, as that would be easier to learn and remember. Unfortunately we lack stats on what is most effective, so are working on gut-feel, guesswork and opinion. Not the best way to optimise quickly, but so it goes. Keeping it flexible and allowing some redundancy may be the way to go in the absence of good data. · · · Peter Southwood (talk): 09:20, 16 January 2019 (UTC)
I have a hunch that navigational aids should be clustered for best visibility. That way the proximity of an unfamiliar aid to a familiar one may help getting the unfamiliar one noticed. Navboxes, portals links, portal bars, subject bars, see also sections, categories are all navigational aids, even external links, references and sister project links can be seen as related, so I think they should all be grouped in one place in an article. Although regular Wikilinks, hatnotes and infoboxes are also navigational aids, their placement is constrained by their function, and inter-language links are tied to the sidebar. There are a lot of options. · · · Peter Southwood (talk): 09:36, 16 January 2019 (UTC)

Concerning section: Required

1. I suggest adding as a requirement the following item:

  • Links to the portal:
    1. From the category of the same name or whatever are the root categories in the Category box section.
    2. From the root article.
    3. From the articles in the selected article list.

Without these links the portal is functionally invisible and does not serve a useful purpose. · · · Peter (Southwood) (talk): 15:36, 7 November 2018 (UTC)

Discussion: linking criteria

Yes, those should indeed be the minimums, and we have a backlog of portals that don't meet those requirements already. — AfroThundr (u · t · c) 17:33, 7 November 2018 (UTC)
It would be good PR to get that backlog sorted out before any more bulk creation. (not restricting experimental work) · · · Peter (Southwood) (talk): 19:02, 7 November 2018 (UTC)
I would support this change. Dreamy Jazz 🎷 talk to me | my contributions 23:28, 28 November 2018 (UTC)
@Pbsouthwood, AfroThundr3007730, and Dreamy Jazz: I suggest #3 be changed to "From the corresponding navigation template(s)."    — The Transhumanist   10:07, 26 December 2018 (UTC)
Or add it as #4 (or bumped to #3, as more relevant, with the above #3 being an optional #4). — AfroThundr (u · t · c) 13:06, 26 December 2018 (UTC)
Portal link from navbox works when there is a navbox to work from, probably as one portal per navbox where the navbox and the portal have a near identical name. Do articles without navboxes get no portal links? Accepted that the new model portals are based on navboxes, so this would generally not be a problem in those cases. There may be some overall gain in binding navboxes and portals in lockstep, but are there any problems this would cause?
AfroThundr's option above allows for flexibility. · · · Peter (Southwood) (talk): 18:08, 26 December 2018 (UTC)
Requiring links that are not part of the page itself? Lacking requirements has historically been a criterion for deletion. But, being an orphan isn't a valid reason for nominating a page for deletion. So, it is unclear what is meant by "required" here.    — The Transhumanist   11:31, 9 January 2019 (UTC)
An orphan portal is a totally useless thing, therefore it is incomplete. The target audience will not know it is there, and it will be ammunition for anti-portalists to attack this project. I think it should be a valid criterion for deletion, and until there is a bot that will do a reliable linking job, the only person that could reasonably be obliged to provide the links is the creator. Until someone comes up with either a bot to do the work, or a compelling explanation of the usefulness of an orphaned portal, I would consider being orphaned a fair reason to delete. I would also prefer not to see panic mode deorphaning from a long list of portals for deletion, as this is evidence of lack of due diligence.
A link from the "below" matter in the navbox provides sufficient linkage to cover this problem, and I would like it to be a requirement where a navbox is used to structure the portal. How it should be done for other portal structures can be left to the creator, but orphans should not be considered to be finished portals. Additional links from wherever they may be useful can be optional. There may be places where links are not appropriate, and other places where they are. Recommendations are fine for them, but there must be at least one as absolute minimum, and only one is not really acceptable either. If someone wants to create a portal they must make it useful, which includes incoming links. As mentioned before, I do not consider it important whether this is done manually, as part of the automation system for portal creation, or soon afterwards by bot, and I can see a place for all of these methods.
Being an orphan is not a valid reason for deleting an article in mainspace, for good reasons, I am not aware that this applies to all other orphaned pages regardless of namespace. · · · Peter Southwood (talk): 05:13, 10 January 2019 (UTC)
Pbsouthwood, although links may not be on wiki, search engines may have still indexed the page, so deletion of such a orphaned portal could disrupt these external links. I agree that portals which are not linked are pretty much useless and that links should be added as a priority. I think this problem should be fixed in part by the bot, although navigation templates would be harder to deal with. Dreamy Jazz 🎷 talk to me | my contributions 13:40, 10 January 2019 (UTC)
@Pbsouthwood and Dreamy Jazz: I think a tweak to the wording to "require at least one of ..." the criteria would strike the proper balance between WP:NOTCOMPULSORY and WP:ORPHAN concerns. That said, if the bot's patrolling game is on point, we'll have full visibility into orphaned portals shortly after they're created, so they wouldn't languish away in that state for very long. — AfroThundr (u · t · c) 23:39, 10 January 2019 (UTC)
@The Transhumanist: What do you think of this? Dreamy Jazz 🎷 talk to me | my contributions 09:18, 11 January 2019 (UTC)

2. We should probably add to this set a link from Portal:Contents/Portals.· · · Peter (Southwood) (talk): 19:07, 7 November 2018 (UTC)

Second that as well. — AfroThundr (u · t · c) 00:29, 8 November 2018 (UTC)
I would support this change. Dreamy Jazz 🎷 talk to me | my contributions 23:28, 28 November 2018 (UTC)
Takes longer to place that link than it does to create the portal. We need to find another solution.    — The Transhumanist   11:31, 9 January 2019 (UTC)
Portal:Contents is a real pig to edit. It is not too bad if you know where the new portal belongs in an exising hierarchy, but if you don't, it is beyond the skills of a regular editor. There are topics which will not fit into its excessively rigid structure, and topics which will fit into more than one place, and we cannot penalise editors for that defect. However, there really should be a link to every portal from it, or it becomes unreliable and loses its usefulness. There is no obvious way that a bot could do this, as it is unlikely to be able to work out where the topic belongs. Who will do this? · · · Peter Southwood (talk): 05:13, 10 January 2019 (UTC)
Pbsouthwood, I don't think it would be able to be done by a bot as you say above. However, my bot could check the wikilinks on the page against every portal, creating a list of portals which are not listed on the contents page automatically. This would be an improvement, but there would need to be editors interested in updating the portal contents page. I am at a stump what could be done here. Dreamy Jazz 🎷 talk to me | my contributions 13:46, 10 January 2019 (UTC)
IMPLEMENTED
Consensus is found for the text in the updated proposal to be implemented. Dreamy Jazz 🎷 talk to me | my contributions 10:29, 16 January 2019 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Poll on this change: linking criteria

Just because this is probably controversial, I think it might be worth to have a support/oppose discussion on this. I propose that from above we make it a requirement (strongly) recommended that there is a link to the portal from:

  1. From the category of the same name or whatever are the root categories in the Category box section.
  2. From the root article.
  3. From the articles in the selected article list.
  4. Portal:Contents/Portals

I propose that, except from the Contents page, this should be automated and also that, except from the Contents page, the links to the portal should be added as soon as the portal is created. I would say that the portal needs to be complete before adding to the Contents page (like it is currently).

Rewritten on the comments by other editors below:

Create a new section called "Linking to portals" as per The Transhumanist. In this section I suggest it says:

To optimize access to portals, each portal should have the following links leading to them:

  1. From the root article of the portal
  2. From the category of the same name or whatever are the root categories in the Category box section.
  3. From the corresponding navigation template(s)

When a portal is complete the portal should be added to Portal:Contents/Portals. Consider adding links to the portal from the selected articles.

Please indicate your oppose/support. Dreamy Jazz 🎷 talk to me | my contributions 09:56, 9 January 2019 (UTC)

pinging @Pbsouthwood, AfroThundr3007730, and The Transhumanist: as they have contributed above and/or in the discussion about the bot that would add some of these links (all except Contents page for now). Dreamy Jazz 🎷 talk to me | my contributions 09:56, 9 January 2019 (UTC)
Pinging again as changed section title to not clash with "Poll on this change" above: @Pbsouthwood, AfroThundr3007730, and The Transhumanist: Dreamy Jazz 🎷 talk to me | my contributions 09:58, 9 January 2019 (UTC)
Please see the updated wording @Pbsouthwood, The Transhumanist, Certes, and AfroThundr3007730: Thanks for your input, Dreamy Jazz 🎷 talk to me | my contributions 12:34, 9 January 2019 (UTC)
  • Support on all items listed in principle, contingent on clarification. · · · Peter Southwood (talk): 10:19, 9 January 2019 (UTC)
    • How does the selected items list differ from the articles listed in the navbox for the new model portals?
    • How compulsory would these requirements be?
    • Who would be responsible for ensuring that they exist? Would they be part of the requirements for portal creation, and how does one deal with amendments to the navbox, which could happen any time as new articles are added, old ones are split, merged or are found to be out of scope for any reason? If they are required, would their absence be cause for deletion?
    • If the intention is to do this by bot (would solve a lot of problems, and answer or make some of the questions irrelevant) what would happen with old model portals? · · · Peter Southwood (talk): 10:19, 9 January 2019 (UTC)
      • Pbsouthwood mentioned "compulsory", an astute observation. Remember the WP:NOTCOMPULSORY policy. You can't force editors to do more than they are willing to. So, you can't say, "You can't work on this page unless you are willing to edit these other pages too." Wikipedia doesn't work that way.    — The Transhumanist   11:41, 9 January 2019 (UTC)
        • @The Transhumanist: I agree that I don't want this to violate WP:NOTCOMPULSORY and would not want this to turn into the same problem as the poll above fixed, however, I feel that the links to the portal should be added wherever possible. Perhaps the text can say something like

Although portals need these links, this is not a justification for deletion, userfying or redirection, nor is this compulsory for you to do this. A bot will add the links if you don't.

The reason I would want this to be "required" is that if it is not then opens up to an editor to decide whether they want to link the portal without reaching a consensus for this. Dreamy Jazz 🎷 talk to me | my contributions 12:04, 9 January 2019 (UTC)
"Required" doesn't fit well, because it has other connotations. I think the concept we are discussing here is what links to portals should be allowed. There has been some opposition to portal links being placed all over the place, including on pages where they are presumed as off-topic. In solving that issue, we should probably avoid the use of the word "required". — Preceding unsigned comment added by The Transhumanist (talk • contribs)
In answer to Pbsouthwood:
  1. I don't think there is a difference. On old-style portals the articles are still in a list of selected articles, so therefore there is a "selected articles list" and in new-style portals they it is navboxes.
  2. I have updated the nom to strike required and instead put "strongly recommended" due to the comments by The Transhumanist below.
  3. As above, I have updated the nom and would also want to include that portals cannot be deleted/userfyied/redirected just because they are orphans. I think that the editor creating the portal should be encouraged to place the links, but this bot should take care of the cases when the editor did not place the links.
  4. Old-style portals seem to be mostly manually maintained now (but not all), so would probably already have links from relevant articles. Because I have changed the the nom to "(strongly) recommmended" I think that these old-style portals won't be affected at all, except that editors may start linking the portal from more articles (hardly a bad thing). I think a bot would check the lead article to see if it has a link and the category, but not the selected article list (unless it was automated) because there is a bit of variation in how the manual article list is structured. Dreamy Jazz 🎷 talk to me | my contributions 12:19, 9 January 2019 (UTC)
  • Oppose use of the word "Required" for this – "Required" refers to features a portal must have in order not to be deleted. But, being an orphan isn't a valid reason for nominating a page for deletion. So, referring to links on other pages would be out of context in the "Required" section. And due to WP:NOTCOMPULSORY, we can ask editors to please add links to the portals they create, but we can't require them to do it, nor can we punish them for not doing it.    — The Transhumanist   11:59, 9 January 2019 (UTC)
The Transhumanist, I have updated the proposal to remove "required" and instead make it "strongly recommended". Have you changed your opinion on this? Dreamy Jazz 🎷 talk to me | my contributions 12:09, 9 January 2019 (UTC)
  • (edit conflict) Conditionally Support the criteria above, but we should've also added: from the corresponding navigation template(s).
    • I also second Pbsouthwood's points above. I think for new-model portals, the linking should fall to the creator to implement, where applicable. Then with a bot periodically checking and generating a report for the portals that fail to meet the above criteria, we could do cleanup runs at our leisure. Not wanting to overload {{Portal maintenance status}}, but it could be useful for tracking these issues, even without Lua, if a bot updates the template.
      • The reports could include an analysis of the article changes mentioned above, most likely using the navbox as the primary vehicle, as any article changes of that nature should be reflected there anyway.
      • More in-depth checks would be determined by how much work the botop wants to put into this, so we won't necessarily depend on them to be wholly accurate, but probably as an indicator of manual checking needed.
    • I don't think these links would individually be a hard requirement, just that the majority of them are accomplished, as sometimes one or two of those won't be applicable to a given portal. I don't think it would be grounds for deletion by itself though. An un-linked portal should be treated like an orphaned article, and could be tracked for cleanup.
    • The bot should be set to not touch portals missing the tag <!-- This portal was created using subst:Basic portal start page -->, to prevent damaging them. We should probably have a tracking category for the un-converted ones anyway to make that easier. Once again, {{Portal maintenance status}} could detect that tag and automatically categorize the portal so the bot won't have to.
    • I also agree that the addition to Portal:Contents/Portals should be done after completion. — AfroThundr (u · t · c) 12:08, 9 January 2019 (UTC)
@AfroThundr3007730: Just in reply to above, I would write a bot that edits the articles directly, although this may take a bit of time, so adding parameters may be unneeded as the bot would do the work anyway. Dreamy Jazz 🎷 talk to me | my contributions 12:38, 9 January 2019 (UTC)
@Dreamy Jazz: That would work great, of course. I was just suggesting that in cases where the edit is not straightforward, the bot could just bug out and tag the portal, rather than trying to automate every edge case. Also, tracking categories tend to increase visibility on these types of issues better than a report page (although the report can give more details), and would allow other editors to manually tag (which the bot could also check and clean up, if desired). — AfroThundr (u · t · c) 13:12, 9 January 2019 (UTC)
  • Partial support I would include 1. and 2. but make 3. optional: "consider adding", perhaps with a prejudice in favour of linking where there's no reason not to. We do need incoming links but there will be cases where they're inappropriate and could be viewed as spam. Certes (talk) 12:15, 9 January 2019 (UTC)
  • Suggestion – Create a separate section called "Linking to portals", and describe the links that "should" be placed, and where. That solves the semantics problem we are having with the word "required". Perhaps use the wording "To optimize access to them, portals should have the following links leading to them:"    — The Transhumanist   12:22, 9 January 2019 (UTC)

Poll on this change: linking criteria (updated)

Please place your support/oppose for the rewrite below. Any comments above referred to the original striked out wording. Dreamy Jazz 🎷 talk to me | my contributions 12:33, 9 January 2019 (UTC)

Create a new section called "Linking to portals" as per The Transhumanist. In this section I suggest it says:

To optimize access to portals, each portal should have the following links leading to them:

  1. From the root article of the portal
  2. From the category of the same name or whatever are the root categories in the Category box section.
  3. From the corresponding navigation template(s)

When a portal is complete the portal should be added to Portal:Contents/Portals. Consider adding links to the portal from the selected articles.

Certes, yes that is what it means. Dreamy Jazz 🎷 talk to me | my contributions 18:40, 9 January 2019 (UTC)
  • Support as well, since the new wording solved the above issues. — AfroThundr (u · t · c) 13:09, 9 January 2019 (UTC)
  • Oppose per my explanation above regarding the incompleteness/uselessness of an orphan portal. Some reasonably effective minimum must be stipulated. Links from the bottom matter of the navbox could be considered sufficient where a navbox exists (this is not onerous, though it requires some template editing skills, or a request to a template editor, and could be done before or after the portal is constructed - some leeway must be allowed - maybe a week?.) For manually constructed and maintained portals, adding incoming links is just part of the manual construction and maintenance that the editor has volunteered to do. If they fail to do it, the maintenance is not being done properly. · · · Peter Southwood (talk): 05:28, 10 January 2019 (UTC)
    Pbsouthwood, I am neutral on this and have been swayed by the other editors above to make this one not required. The bot (if approved) should be able to ensure that these links are added, but obviously the wording "should" would allow leeway. Dreamy Jazz 🎷 talk to me | my contributions 13:49, 10 January 2019 (UTC)
    Note: some navboxes such as U.S. places use fixed templates which discard any attempt to add a footer and are protected. I inquired but got no reply on a talk page. Certes (talk) 14:24, 10 January 2019 (UTC)
    Certes, I'll implement this. There has been no attempt to disagree with you in well over 6 months, so it I'll be bold and implement this. Dreamy Jazz 🎷 talk to me | my contributions 18:33, 11 January 2019 (UTC)
    Dreamy Jazz, I don't follow your statement directly above. Cheers, · · · Peter Southwood (talk): 18:44, 11 January 2019 (UTC)
    Pbsouthwood See Template_talk:US_state_navigation_box#Below Dreamy Jazz 🎷 talk to me | my contributions 18:46, 11 January 2019 (UTC)
    Got it, I have left a comment there supporting a change. · · · Peter Southwood (talk): 19:04, 11 January 2019 (UTC)
    I foresee pushback from other quarters if there is no requirement to have links to portals. I would consider that justifiable. Cheers, · · · Peter Southwood (talk): 18:51, 11 January 2019 (UTC)
    The problem is, that it implies the breaking of a rule, with punishments to follow. You don't want to punish an editor for creating a page. That is the exact opposite of the wiki-way. There is a clear distinction between "we should have links" to "you must place them, or else." The second one is draconian, as it implies deletion or a block. We want to build roads (guidelines) upon which editors can travel of their own will, not force them where to go with threats and whips. Wikipedia is a fun place to collaborate with others to build a free information source for the world. Please, let's keep it that way.    — The Transhumanist   20:57, 11 January 2019 (UTC)
    • Beware of all-or-nothing-reasoning. Incomplete = partially complete. Free work. Ready and waiting for others to build upon. A glass half full. Ready for drinking...
This situation reminds me of the basic topics lists. These were a set of about 30 orphan pages, just sitting gathering dust for years, in project space. Eventually, someone (me) came along and discovered them, and decided to make them non-orphans, and move them to article space, where they grew to around 300. Eventually, they were renamed to "Outlines" and grew into one of Wikipedia's main navigation systems. There are now over 700 of them. It is a good thing those lists were not deleted just because they didn't have links to them. If those lists weren't there for me to come across to be inspired by them, the outline system may not even exist...
Requiring that an editor place links to a portal he or she wishes to create may deter that editor from creating it. We want to encourage, not discourage portal creation. Editors are allowed to specialize. If an editor has a knack or desire to create portals, that is a positive thing. We need to feed, not dowse, their creative spark. It is better to have orphan pages than not have those pages at all. I look at them as part of the job being done. Because page creation puts us one step closer to having pages with links to them. This is a collaborative environment, where editors build upon the work of each other. Orphan pages are islands. New places to build bridges to. And therefore, valuable. You can't build a bridge to an island that doesn't exist. Some editors like to build islands, and some like to build bridges. What a great combination. More new islands, please...
Another analogy that fits here are plants in a nursery. They are orphans, without a garden. Should we get rid of them because they are not planted in a garden yet? No. Flowers are nice. Make them available to gardeners who will plant them in their final locations...
That a page isn't transplanted yet cannot be a deletion criterion. Each page is judged on its qualities whether or not it should be kept or deleted. That other pages lack links to a page is not a valid deletion argument, and if it was, thousands of well-written stubs (flowers waiting to be transplanted) would be subject to the compost pile (deletion) right now, regardless of their quality. Getting rid of them, would be a step BACKWARDS...
Three different programmers are working on automated (or semi-automated) solutions for placing links to portals. Why? Because we have thousands of portals that need them. Thousands of healthy plants waiting to be transplanted. Without those new portals sitting there waiting to be linked to, there would be little or no impetus to do this. So, bring them on! More portals, please.    — The Transhumanist   19:49, 11 January 2019 (UTC)
I have a suggestion that might fix this problem. Perhaps another sentence should be added to the proposed text to say that if an editor (or BRFA approved bot) wants to add a link to a relevant portal, they shouldn't be stopped? This could be something like If an editor or BRFA approved bot, adds or wants to add a link from one of the above pages to the portal for the topic directly relating to the page, they must be allowed to. If the editor or BRFA approved bot does not hold the rights to make such an edit, an editor with appropriate rights can do this for the editor. This would get around the WP:NOTCOMPULSORY problem, in that an editor does not have to add the links, but also ensures that if this editor or another editor who wants to add a directly relevant portals when added can't be just reverted on grounds without discussion. What do you think? Dreamy Jazz 🎷 talk to me | my contributions 19:16, 11 January 2019 (UTC)
The guideline proposed above, recommending the placement of links to new portals, is fine. We want to encourage linking, not demand it. Because if you make it a rule, it will be broken, and one of the things that sometimes happens when a rule is broken is that someone gets punished. In this type of case, it would be punishing an editor for doing something positive: creating a new page. In other words, for building an encyclopedia, the very purpose for which we are here. The case would go to the Arbitration Committee, who would have no other choice than to quash the rule leading to such ridiculous punishment. Upon reading "You stand accused of growing a new plant without planting it in the garden. How dare you! You can never grow plants again!" They would laugh their asses off. Growing new plants, that is, creating new pages, is one of the main reasons Wikipedia exists.    — The Transhumanist   20:07, 11 January 2019 (UTC)
The Transhumanist Fair enough. The rule I suggested does not require the creator to place links, but says that if an editor or bot wants to add the link they should be unimpeded, but only for those 3 pages. I can, however, see that rules/musts would not be supported by the majority, so won't add this to a proposal unless this changes. Dreamy Jazz 🎷 talk to me | my contributions 20:12, 11 January 2019 (UTC)
Good point. I believe your concern is taken care of by the phrase "should have the following links leading to them", which strongly implies that "placing these links should not be impeded". The implication is already there, pretty strongly, because the guideline is guiding that such links should exist and should be placed. If someone removes such links, or opposes their placement, the editor placing them can point to this guideline.    — The Transhumanist   20:21, 11 January 2019 (UTC)
I agree with TTH, that the proposed verbiage in this guideline would be sufficient protection for link placers. — AfroThundr (u · t · c) 20:28, 11 January 2019 (UTC)
I play devil's advocate here because I foresee someone taking this to full RfC via VP (proposals). I would prefer not to see the kind of dramah that might be brought upon the project if that happens. I would particularly not like to see any of the members ending up with blocks or topic bans if goaded into intemperate bahaviour. That would not help build the encyclopaedia. If you are all in favour of this not being a requirement, I will go with the consensus, but would point out that it is a fairly local consensus, and could quite plausibly be overthrown if taken to the full community, because I do not think that the reasoning is sufficiently robust.
The reasoning that portal space is necessarily subject to the same requirements as mainspace is dubious. An incomplete article in mainspace is subject to a small but rather strict set of requirements, all of which are intended to ensure that the article is useful. Usefulness or potential usefulness to the reader is the prime directive for mainspace. Any article in mainspace that is not useful, or potentially useful, as encyclopaedic content is unlikely to survive RfD.
It is clear that virtually any portal is potentially useful, but nevertheless we have requirements for portal creation, because it would be possible to create a portals which would require a great deal of additional work to become actually useful. Links to a portal so that it can be found is a quantum increase in actual usefulness, and likewise a decrease in the burden on other editors who would otherwise have to fix the consequences of someone else's failure to do a proper job. I recognise that we are all volunteers, and do not have to fix other people's errors and omissions, but that is what a large number of our editors do all the time to keep the encylopaedia in as good a condition as we can. Opening another door to making work for others that would keep them fom more useful work is not optimum. If the number of orphan portals grows large enough there will be an unacceptable additional burden on those trying to clean up the mess left by others, whether through inattention, ignorance, malicious intent or lazyness. If this gets big enough there may be a further attempt to close portal space. I would not like to see that happen.
I do not see a fundamental difference brtween the existing requirements and this proposed one. All of them address the usefulness of a portal. This one is arguably more necessary because even an badly formed and formatted portal is immediately more useful than an invisible portal. · · · Peter Southwood (talk): 18:21, 15 January 2019 (UTC)
Pbsouthwood, I think that the consensus here is to go for the revised proposal.
I understand that our local consensus could be overridden, but feel that if an editor has problems with the text here they would take it to RfC, like you say. If this was the case then so be it. I would say that discussion over guidelines does not always merit a RfC nor going to the VP.
Also, my bot would ensure that these links are added for new portals, so the potential for any orphaned portals would be next to none (unless someone deliberately stopped the links from being added, or the portal has no introduction/category sections, which then wouldn't meet the "Required" section).
Thanks and happy editing, Dreamy Jazz 🎷 talk to me | my contributions 22:49, 15 January 2019 (UTC)
Dreamy Jazz, You are probably right on the local consensus. I think this may come back to bite us, but do not consider this a very high probability, and will go with the flow.
Your bot is the main reason why I will go with the flow. I look forward to it doing the work and making the problem go away in practice. If anyone deliberately blocks the bot, they thereby take responsibility for the lack of links. If the links were a requirement there would be a stronger argument that blocking the bot would be disruptive, but strongly recommended still provides a bit of pressure. Cheers, · · · Peter Southwood (talk): 09:02, 16 January 2019 (UTC)
Pbsouthwood. Ok. Per [I]f the consensus is clear, any editor—even one involved in the discussion—may close the discussion on Wikipedia:Administrators' noticeboard/Requests for closure coupled with that discussion has been open for a week (so it has given editors time to respond to this) and you and other participants agree that the consensus is for the addition, I will close this and add it to the guideline. Dreamy Jazz 🎷 talk to me | my contributions 09:58, 16 January 2019 (UTC)
Pbsouthwood On second thoughts, this discussion does change a guideline. Should I take it to the noticeboard? Formal closure by an uninvolved editor or administrator should be requested ... where there are wiki-wide implications, such as when the discussion is about creating, abolishing or changing a policy or guideline. Dreamy Jazz 🎷 talk to me | my contributions 10:09, 16 January 2019 (UTC)
Pbsouthwood On third thoughts, this is not really a "wiki-wide" discussion, as it won't affect every page. Therefore, I feel that I don't need to take it to the noticeboard. Dreamy Jazz 🎷 talk to me | my contributions 10:27, 16 January 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Should Portals contain noticeboards?

There are a few portals that also have a noticeboard-type subpage; my view is that these subpages should be in the Wikipedia:WikiProject space and not in the Portal: space. What do other editors think? UnitedStatesian (talk) 19:51, 10 January 2019 (UTC)

@UnitedStatesian: Well, considering one of the purposes of portals is to serve as a bridge between the readership and the editorial population of Wikipedia, things like noticeboards or WikiProject links, are not necessarily out of place, depending on the context. Do you have any particular examples that raise these concerns? — AfroThundr (u · t · c) 23:26, 10 January 2019 (UTC)
The four that are in the portal space are Portal:Armenia/Armenia-related Wikipedia notice board, Portal:Azerbaijan/Azerbaijan-related Wikipedia notice board, Portal:Ukraine/Ukraine-related Wikipedia notice board, and Portal:Vermont/Vermont-related Wikipedia notice board. My only concern is that users will not know where to find them if all the others noticeboards are in the Wikipedia:WikiProject space. I think I will go ahead and move those four if there are no strong objections here. UnitedStatesian (talk) 13:33, 11 January 2019 (UTC)
I agree with UnitedStatesian that noticeboards belong in project space. While portals are to serve as bridges to WikiProjects, they are not intended to be WikiProjects. The "bridges" referred to in the guidelines are links to project space, typically links to related WikiProjects.    — The Transhumanist   18:13, 11 January 2019 (UTC)
Ok, yeah.. In that case, those pages should be moved to a relevant WikiProject, where they'd (hopefully) be more useful. A link to the WikiProject should be sufficient for the portal itself, and the project page can link to a noticeboard from there. — AfroThundr (u · t · c) 20:30, 11 January 2019 (UTC)
I agree that these noticeboards belong in project space not portal space, but it can be useful to transclude them on a portal rather than providing just a link to a WikiProject. A typical reader might not know what a WikiProject is and would therefore be reluctant to click on such a link, but if presented with a list of things they can do to help Wikipedia, they might be more inclined to get involved. I think that was the logic behind including them in portals to begin with, and it still holds good. WaggersTALK 14:30, 23 January 2019 (UTC)
If I remember correctly, the old style portals sometimes transcluded a "To do" subpage from the relevant project. There is one in Portal:Underwater diving. I have mixed feelings about them. On the one hand they do provide some potentially useful information about what is still to be done in the scope of a project, but on the other hand, they can be quite big and in your face. I would be interested to hear more impressions and opinions. I agree that the information belongs in the project, so if there is no project it is a bit pointless. To me the question is whether it is worth having them in the portal in addition to the project, i.e. by transclusion, and whether this is a thing that should be mentioned in the guidance. Also whether there should be limits to what kind of information is considered appropriate. Cheers, · · · Peter Southwood (talk): 15:54, 23 January 2019 (UTC)

Notability Discussion: Revived

Moved from WT:WPPORT § Notability Discussion: Revived
 – — AfroThundr (u · t · c) 04:23, 6 November 2018 (UTC)

Much as we may wish it were so, this discussion isn't over yet. The conversation got a bit heated at times, and then it was basically just dropped with no resolution. Rather than truck out ~120kB of threads from the archives, I'll post them here, for convenience:

Original discussion of portal creation criteria
FYI
 – This conversation was also posted at the deletion discussions listed here. — AfroThundr (u · t · c) 16:49, 26 September 2018 (UTC)

This is mostly prompted by the recent MfD spree of a dozen newly created portals of varying scope and notability (most of which seem ok to me, but I digress). Our portal guidelines are still missing an important section: criteria for creation. We've talked before about drafting and codifying notability and other criteria to determine where the line is drawn for portal creation, and after the (mostly duplicate) discussions across those MfD's, I think it's time we finally sit down and hammer out something we can all live with, and build a set of criteria that might survive an RfC.

As a prompt, I'll take this back to the first thread I know of to discuss this matter: from WP:ENDPORTALS. I'm sure everyone here remembers that historical, semi-recent attempt to axe the entire portal namespace, which resulted in a no-consensus close and the reboot of this WikiProject. While creation criteria and notability were sprinkled all around that discussion, perhaps most relevant is the section WP:ENDPORTALS § Notability for Portal, which I have transcluded below for convenience:

Notability for Portal

An alternate solution to poorly maintained portal on narrow topics can be establishing “Notability” / Significance criteria for Portals which currently does not exist. Since WP strictly enforces notability criteria for articles, it only makes logical sense to have at least some minimum criteria for portals. There can be several approaches on how notability can be established, like:

  1. . The core portal topic must be at least a Level-3 Vital Article.
  2. . There must be minimum X number of Featured / Good articles that can be shown on the portal.
  3. . The portal must be a level 3 or 4 sub-portal of the portals linked to the main page.

Please feel free to add why this may or may not be a good idea, or any alternative thought on how the “Notability” / Significance criteria can be established. Arman (Talk) 04:53, 25 April 2018 (UTC)


I agree to the idea in principle, but not in the specifics suggested above. Portals need to be understood as merely "Topic Overviews" or "Topic Tasters", and we should make them far more visible in Hatnotes, DAB pages, See Also and, especially, in Search results. As "Topic Tasters", they should exist only to introduce users to a broad subject area or theme at any level, and in a manner that single articles spectacularly fail to do. So, it's breadth and depth of subjects covered that is really important, not the current quality assessment of individual components. Have a minimum number of article linked from it, by all means, but do not require each to have a predetermined quality grading. This applies to Levels, too, I suspect. Portal:Mountain and Portal:Alps are at different levels, but they each serve as good, visual Topic Tasters to a very broad range of detailed content. Most importantly, they reach out and link sideways across other content at varying levels. So maybe judging Portals by that ability to link sideways is key here. As I'm not that familiar with the Wikipedia:Vital articles and their Levels, I can't offer more specific suggestions. But Portals are not Articles, so judging them by single article level doesn't seem appropriate. It's their function as a Topic Taster (and making them findable in the first place, and therefore functional) that should count towards an assessment of notability. If they don't give an overview across a wide range of subjects then they're probably not likely to be deemed noteworthy. Nick Moyes (talk) 08:24, 25 April 2018 (UTC)
Although it's tempting, I'm not sure notability is the right criterion as it's quite subjective and will result in energy-sapping discussions. What is more critical is the willingness of WikiProject teams to commit to supporting one or more portals. That's pretty easy to assess. If they do, the portal should be well maintained and high quality. If they don't, it could be a candidate for deletion if the quality is poor. Bermicourt (talk) 19:04, 25 April 2018 (UTC)
I very much like the suggestion to view portals as "topic taster" pages. I essentially agree with Bermicourt that quality should be enough as a measure whether we should keep or delete a portal -- for topics of fairly low notability (say, my local shopping mall) it will be really hard to make a halfway decent portal. But if somebody succeeds in creating an appealing and balanced portal, we don't gain by throwing it away. —Kusma (t·c) 19:19, 25 April 2018 (UTC)
German Wikipedia makes this easier by having guidelines on what definitely constitutes a valid portal (they call it 'relevance'), e.g. countries, major sports, capital cities, and saying that the rest should go through an approval process. I've translated (and slightly tweaked) their guidelines here. Maybe we could do something similar. Bermicourt (talk) 19:05, 30 April 2018 (UTC)
I am against notability guidelines. The Quality of a Portal is important. If the Quality is high enough, I do not care about notability.--Broter (talk) 16:09, 1 May 2018 (UTC)
I don't think that "notability" is the right measure either. I do think we need to have some kind of guideline or measure in place to make sure that portals do not get too granular.--Paul McDonald (talk) 16:19, 1 May 2018 (UTC)
These "relevance guidelines" are a good idea. In response to the concerns expressed by the last two users above, there's no requirement for us to make to guidelines rigid (per WP:IAR, if a rule prevents us from making a good, relevant page, well then ...). Actually, there is no reason to delete the portals whatsoever - we should use the same criteria as for Wikiproject pages - namely, if the pages are not well maintained or frequented but fall short of being "entirely undesirable", they can be tagged with {{WikiProject status|inactive}} or a (new?) variant thereof. 198.84.253.202 (talk) 18:04, 1 May 2018 (UTC)

Can we perhaps agree that at minimum a portal should:

  1. be related to a notable topic (i.e., one with an article that is not likely to get deleted)
  2. have a parent portal (so, no "orphaned portals") [edit: except for a small number of "top-most" portals — see discussion below]
  3. have no missing/broken sections (like this)

Portals lacking these features could be tagged for refactoring (i.e., to be about a more general topic if #1 or #2 is the problem) or further improvement; in extreme cases, they could be deleted/archived. Obviously, plenty of opportunity would need to be given for interested editors to satisfy #3 before it could be used as justification for deletion/archiving. The details of "implementing" these principles could be worked out later, but I think "portals worth keeping" should satisfy these three conditions. Right? - dcljr (talk) 18:06, 1 May 2018 (UTC)

No. 3 seems good in principle, but in practice WP:NODEADLINE is a thing to consider and currently there is no policy which allows for deleting articles (or any other pages) because they are a "work in progress". No. 2 is good, but when pushed to its limit it becomes an infinite regress - of course, its possible to make "exceptions" to this "rule" for top level portals. Nevermind - No. 2 is good, too, assuming it can be linked reasonably (and without being an excessive split) to a parent portal (given that there is indeed a "parent of all portals", Portal:Contents/Portals). No. 1 is perfectly acceptable, though. 198.84.253.202 (talk) 18:12, 1 May 2018 (UTC)
Oh, yeah, for #2 I was implicitly exempting the "top-most" portals—say, those currently linked to from the Main Page, or, as you point out, those that are / could be listed as the most general portals on Portal:Contents/Portals. - dcljr (talk) 20:52, 1 May 2018 (UTC)
It seems silly to me to require that a portal be about a notable topic. If it's not about a notable topic, then the links in the portal will all be redlinks because any articles in the portal would be deleted at AFD... but then again... okay it still seems silly, but that doesn't mean it isn't a good idea too.--Paul McDonald (talk) 05:25, 2 May 2018 (UTC)
I much prefer Arman's criteria. 2 (once amended) seems absolutely critical. 3, while not vital, seems a fairly minimal standard to require. 1 actually might be a little under-strict: as noted, non-notable articles shouldn't be there, and if they aren't, it will just be redlinks. Should some qualitative requirement (not nearly as high as seen in the first mooted set) be needed for the primary article? E.g. a tested B standard? Nosebagbear (talk) 11:05, 2 May 2018 (UTC)
I agree with the minimal standards by dcljr. This should be required for every Portal!--Broter (talk) 13:25, 2 May 2018 (UTC)
I also agree with this. Under the above criteria, we could trim a significant amount of tiny, neglected, and unmaintained portals, and make our jobs of curating the rest easier. Having better guidance on when a portal should (or should not) exist is something we should work on. These criteria would be a good start on that. — AfroThundr (talk) 20:10, 7 May 2018 (UTC)
@Paulmcdonald: From what I see, no. 1 is indeed obvious, but it should still be stated clearly (something like "General guideline: there should already be at least a few (more than one) well-developed (not necessarily FA or GA, but more than start or stub class) articles about the topic") so as that it is clear in everyone's mind (even those who haven't discussed it here at the RfC). 198.84.253.202 (talk) 03:32, 4 May 2018 (UTC)
I mean it certainly wouldn't make sense to have a portal without at least 4 or 5 (at least!) articles to put into it. Having a "B" standard for the primary article and some general bit for a few more entries at least seems reasonable. (I don't think anything like "at least 3 more C or above articles" will help encourage portal upkeep!) — Preceding unsigned comment added by Nosebagbear (talk • contribs) 10:00, 10 May 2018 (UTC)

There were several other attempts I recall to get this discussion started shortly after the reboot, but they're buried in the archives somewhere. Let's see if this one sticks. So, what do you guys think on the matter? What criteria do you think a potential new portal should meet before it can be created?

Creation criteria discussion

@The Transhumanist, Evad37, Certes, Dreamy Jazz, Pbsouthwood, SMcCandlish, FR30799386, BrownHairedGirl, Godsy, Finnusertop, Cactus.man, and BrendonTheWizard: Pinging recent participants in the WikiProject and the MfD discussions. — AfroThundr (u · t · c) 16:54, 26 September 2018 (UTC)

So far, the main metric being cited is number of articles on the subject. The issue with that may be self-apparent to most: not all topics are created equal. Any number that would be sufficient for many topics may set the bar far too high (or too low) for others. I do, however, like the idea of linking them to vital articles, or the requirement for the main article to be rated a certain class or higher. If those aren't notable enough, I'm not sure what is. I also like the taxonomic suggestion that no portal can be standalone or orphaned. Ideally, all portals should have a parent and siblings that the reader can navigate like breadcrumbs to get to related topics. The rest of that section covered maintainability, which we've got in spades. — AfroThundr (u · t · c) 16:27, 26 September 2018 (UTC)

  • I think that we should have a guideline, but, I feel that it shouldn't be too strict. I think that because portals act as a kind of navigation aid, a portal should not exist unless there are enough articles/pictures to make the portal seem finished. Also, I feel that we should ensure that the articles used are are of a certain quality rating or higher, because we are now so heavily reliant on transcluding leads from articles, having a portal based on stubs with small or no leads makes the portal also seem incomplete and empty.
I also think that having some kind of breadcrumbs link as AfroThundr3007730 mentioned is a good idea, but this could cut of having portals that do not necessarily have parents. Dreamy Jazz 🎷 talk to me | my contributions 17:01, 26 September 2018 (UTC)
Although "not topics are created equal", I still feel that if a topic does not have the articles on it, then those articles should be developed first, as I feel a portal acts as a way to find articles / similar topics, so not having the articles to link to is like having an empty or small contents page, which is inadvisable. Dreamy Jazz 🎷 talk to me | my contributions 17:06, 26 September 2018 (UTC)
Some ideas to consider:
  1. I like the idea of a link to a higher level portal. Not sure if it should be a requirement, but am open to debate. There is almost always a possibility for a parent portal. If there are counterexamples, I would like to see a few. Siblings may or may not exist. A breadcrumb trail could be a nice touch. Breadcrumb trail upwards, box(es) of sub-portal, sister portal and related portal links downwards and sideways.
    • How do we do breadcrumb trails for portals with multiple parents? Several in parallel?
  2. If there is a reasonable navbox, that may serve as the criterion for having a portal on the same topic, as the current system relies on the navbox for structure, but there is room for improvement.
  3. A portal made up of mainly stubs and few substantial articles should be discouraged. First get the articles, then make the portal. If there are enough substantial articles, the number of additional stubs should not matter.
  4. Images are nice but cannot be a qualifier as some topics have very few useful images. Same with news, quotes, did you knows etc, which are mainly decorative.
  5. There should be a category of similar name and overlapping content. There may be cases where it does not exist, but then either the portal is frivolous or the category should be created. Navbox and category will usually have a large intersection.
  6. Special cases should be considered on their merits.
  7. Portals that are large and cumbersome will usually be suitable for splitting into sub-portals, based on rationalising the navboxes. I am experimenting on these lines with Portal:Underwater diving, which is in a state of flux, but demonstrates sub-portals/sister portals based on navboxes. Underwater diving is also one of those topics which does not have an obvious unique parent, as it could be a child portal of several, and the sub-portals could be sub-portals of various other parent portals. The network could get quite complex. · · · Peter (Southwood) (talk): 20:34, 26 September 2018 (UTC)
  8. New single page portals are cheap to make, we can lose a few if they are not good enough yet and no-one is available to fix them quickly, but they can be recreated as soon as the topic is ready. That which is deleted now can be undeleted when the time is ripe. · · · Peter (Southwood) (talk): 20:57, 26 September 2018 (UTC)
You mentioned stubs. Keep in mind that our lua gurus have built-into the transclusion modules a stub filter, so that articles tagged as stubs are not displayed in portal slideshows. So stubs shouldn't be a concern. (Remember to show your appreciation to these guys, for the amazing features they have enabled in portals).    — The Transhumanist   06:21, 27 September 2018 (UTC)
@Dreamy Jazz and Pbsouthwood: These are all good points. With regards to the breadcrumbs, I'm thinking they should trace the direct lineage back to the top-level portal it descends from, and in the case of multiple parents, it would just show the main (primary?) parent, or even list two breadcrumb trails. If resolving one of those trails results in another split, the "primary" link is chosen. I think that could be implemented with minimal confusion to the readers (and editors). As for the child and sibling portals, I think each portal should only show their "immediate family" not extended cousin or nephew portals (this metaphor is getting weird). If such a network becomes tedious to maintain by hand (highly likely), we could use Lua to pull Wikidata relationships to track the genealogy. — AfroThundr (u · t · c) 04:05, 27 September 2018 (UTC)
I think I follow your explanation, and it looks OK. It will probably be quite simple for most portals and horribly complicated for a few. So it goes.
Wikivoyage has a breadcrumb system that, if I remember correctly, only requires the immediate upward link to be made by the user, and automatically follows the existing trail to the top. It is only used for one trail per article, because they structure the site quite rigidly to make that possible. I have no idea whether linking upward to two parent portals would work, but would guess that it will either work all the way up or crash immediately.· · · Peter (Southwood) (talk): 12:07, 27 September 2018 (UTC)
{{Breadcrumb}} works but each portal would need to list all its ancestors explicitly. We might create a variant where the portal just needs to name its immediate parent, with the trees above there recorded once, perhaps in the template itself. Certes (talk) 12:34, 27 September 2018 (UTC)
  • What are the benefits of a portal? When is a root article with a portal attached better than a root article without one? And why? For example, is Quidditch (sport) a better encyclopedia page because is has a portal link in its See also section? And how do users make use of portals? How should we go about finding this out?    — The Transhumanist   00:02, 27 September 2018 (UTC)
@The Transhumanist: please can you clarify whether you gave any thought to that what are the benefits of a portal question before you went on a rapid-fire spree of creating hundreds of them at a speed which sometimes exceeded over 40 per hour?? What conclusions did you reach then? And have you reconsidered those conclusions in light of subsequent discussions? --BrownHairedGirl (talk) • (contribs) 01:05, 27 September 2018 (UTC)
I wonder how receptive the WMF would be on providing us more detailed analytics on Portal namespace traffic (enwiki and possibly dewiki). I'm talking things other than just generic pageviews. They run traffic studies all the time, so the infrastructure is already there. I'm guessing we'd also need to shanghai an analyst to parse that down for us, since I don't see them handing us the raw dataset (not without identification at least). — AfroThundr (u · t · c) 04:14, 27 September 2018 (UTC)
BrownHairedGirl, I can attest that The Transhumanist has spent a considerable amount of effort on thinking about whether there are benefits to portals. The question above relates more to whether there is any data available. We have discussed this at length, and agree that they are potentially (and probably actually) useful, but we do not have any statistics, so hard to express a probability with any confidence. This was not done without consideration, but conclusions may differ, as they all appear to be based on personal opinion so far. · · · Peter (Southwood) (talk): 05:51, 27 September 2018 (UTC)
@Pbsouthwood I am sure you write in good faith, so I would like to believe you. However, TTH's many replies at MFD show near zero evidence of having done any such thought, as did their post[10] on my talk asking me to withdraw the Pebble Beach MFD ... a micro-portal which TTH subsequently G7ed after others agreed with my assessment of its narrowness. TTH's MFD comments repeatedly amounted to verbose technical descriptions of how portals work rather than why that particular one had sufficient scope to add meaningful value, and at one point he even expressed deep indignation that a portal was MFDed before it was complete because how TTH know its utility before it was fully built. That indicates little or no prior assessment, so I'd like to see TTH respond in their own words.
I am disappointed to see you joining several editors in this discussion talking of "personal opinion" to dismiss other comments. We reach consensus by having reasoned discussion and assessing what evidence is available. I have shown evidence both that narrow-scope portals are little used and that extensive promotion does not significantly raise usage levels. So we would be more likely to sustain courteous and constructive discussion if you refrained from the discourtesy of airily dismissing my evidenced assessments as "personal opinion", which implies that there is no evidence involved.
Sure, the data which we have is limited, and we could have a sensible discussion about the significance of the evidence gaps. It would be great if @AfroThundr3007730 could get more detailed usage info, but I seriously doubt that it would significantly alter the picture. There are so few examples of widely-used portals that there is little chance of learning much new about what makes them successful.
I am concerned that in both your reply and TTH's mass-creation spree the approach you describe seems to me to amount to "inconclusive evidence of utility, so let's massively increase the rate of creation". Apart from inherent perversity, that seems brazenly dismissive of the ~150 editors who at WP:ENDPORTALS expressed support for a mass cull. --BrownHairedGirl (talk) • (contribs) 06:40, 27 September 2018 (UTC)
BrownHairedGirl. Thank you for your explicit assumption of good faith. It is not misplaced, and I extend the same courtesy to you. If you want documentary evidence of considerable thought and discussion, it exists on my talk page and its archives, The Transhumanist's talk pages and archives, in the project newsletters and project talk pages. Whether all possible aspects were exhaustively considered is a claim I will not make, but a lot of discussion exists if one wants to examine it.
If I appear to be airily dismissing your evidenced assessments as personal opinion, I apologise, as that was not my intention. The comment about personal opinion applies equally to my opinions and those of the members of this project, and was not aimed at you specifically. I would however like to see your evidence, as I don't have any, and assumed that no-one else does either. I have been wrong before, but am amenable to evidence based correction.
I don't think I have even expressed my opinion about how fast portals should be created. I am not supporting the current rate, I am defending some of the reasoning behind it. I do not see this as a black and white issue, and do not even know how grey it is.
Have you examined the code of a new model portal? I ask this for background, as it would affect how I might explain my opinions, and do not wish to make an assumption either way. Cheers, · · · Peter (Southwood) (talk): 07:18, 27 September 2018 (UTC)
@Pbsouthwood: no, I have not examined the code of a new-style portal, and I do not intend to do so ... because I do not see how the coding alters the well-evidenced fact that microportals get microviews. If you would like to present some concise explanation of how the code has altered pageviews, I would be delighted to read it it.
As to my evidence on pageviews, I have presented some at MFD and some elsewhere on this. I do not intend to collate it, because I am pretty sure that anyone working on portals knows the data: that only the ten most-used portals even top 400 daily pageviews.
I hope you will understand why I am not going to trawl archives and multiples user pages for snippets of discussion. I assume that responsible editors follow WP:MULTI -and centralise discussion so that it can read and joined by others. It is those centralised discussions and proposal formations which I would be interested in seeing, if yo can offer any links. But I note with alarm the lack of discussion at WT:PORTAL. Not a good sign. -01:07, 28 September 2018 (UTC)
  • Many thanks to @AfroThundr3007730 for starting this discussion. After the community reached a consensus at the RFC not to delete all portals at this time, this project had a reboot and some great work was done to improve the templates. Sadly, that good work does not seem to have been accompanied by similar attention to the main issue raised in the RFC: that most portals get very few views. With the exception of a very few broad scope portals, readers hardly use them. Over 150 editors supported either deletion of the whole portal namespace or a massive cull. There is absolutely no evidence of broad consensus for a massive expansion of portals, or for adopting low scope thresholds.
Some commentary in various place suggested that low usage was due to inadequate promotion. However, I have evidence to the contrary, wrt Portal:Years. Earlier this year, User:Fayenatic london and I did a lot of work on adding automatic portal links year-in-foo categories. One of the results of that is that there are now 393,762 links to Portal:Years ... but it still has a 90-day average of only 16 pageviews per day. The conclusion of obvious: promotion has not helped, and readers don't want that portal.
Similarly, Portal:France has only 75 daily pageviews vs 15,000 views per day for the head article France ... and >11,000 daily views] for London vs 36 daily views for Portal:London. Or 10,000 daily views for Queen (band) but only (band) 17 daily views for Portal:Queen (band).
Despite obvious community disquiet about the v low usage levels, the Portals Project seems to have concerned itself primarily with the how of portals, and not the why and what. On the contrary, Wikipedia:WikiProject_Portals#The_current_plan says Create new portals for all the core topics that have enough coverage to need a portal, and for whatever other topics portal creators are interested in. The lack of guidance about what constitues "enough coverage to need a portal" is a bizarre oversight, and the "whatever interests a creator" is silly. This failyre to define thresholds seems to me to be serious collective case of WP:IDIDNTHEARTHAT.
So the result has been that one editor (The Transhumanist (talk · contribs · deleted contribs · logs · filter log · block user · block log)) has been engaged in rapid-fire creation of small-scope portals: over 400 in the last 12 days, sometimes with only a few minutes between them (e.g. on 22 Sept, 9 new portals created in 60 minutes, or on Sept 17th 73 new portals created in 91 minutes). That clearly involves no scrutiny of the scope or viability of the portal .. and shockingly, the same editor has specifically objected to being asked why they chose to create a portal with a particular scope, at least until the portal has been completed. That is a daft way to approach any such task: the very first step should be to be assess whether the topic is suitable for a portal.
The failure so far of this project to address any of these issues is stoking up trouble for the future. The "keep" votes at MFD seem to have come overwhelmingly from a few regular participants in this project; there is no sign of wider community for the new microportals. Even the portal-project keepvotes have mostly been qualified.
My own view starts from the fact that portals are not content; they a device for navigating between content pages. We already have tools for navigating small sets (lists, categories and navboxes) ... so a portal should be a gateway to a large collection of info, not simply a shelf with a few dozen items. I deplore the attempt to use portals simply as a different way of presenting the list of titles in a navbox.
My preference would be for guidelines that restrict portals to:
  1. broad topics: e.g. a country rather than a county or village; a musical genre rather than a single band; a literary movement rather than a single writer; a sport or league rather than a single team.
  2. topics whose scope extends to at least five thousand non-stub articles, at least a dozen good articles, and preferably a few feature articles/lists.
  3. topics where a properly-advertised discussion has shown that there is both a consensus to create it, and a group of several experienced editors who are willing to commit to maintaining it.
Others clearly have different preferences, so we need an RFC to find a broad consensus. I would be happy to work with other editors to draft such an RFC to be posted in a neutral location such as WP:VP ... but in the meantime I strongly urge this project to recommend a moratorium on the creation of new portals until such an RFC is concluded.
I also recommend that before an RFC proceeds, there should be some collaborative effort to collect evidence on the usage of portals, and on whether difft types of promotion have an effect on usage. --BrownHairedGirl (talk) • (contribs) 00:51, 27 September 2018 (UTC)
@BrownHairedGirl: Lots of good stuff there. I'm just going to poke at a couple of points, since I don't have time to post my own wall of text in response.
  1. New portals - While I agree that the new portal creation should be slowed considerably until we have a decent set of criteria in place, I don't think it needs to stop entirely. Instead of starting with the "low-hanging fruit" at the bottom of the hierarchy, we should instead be filling out the top-level subjects that are still missing (a la the vital article topic list on the project main page), then work our way down from there. By the time we reach questionable eligibility territory, we should (hopefully) have guidelines in place. Or if we're still spinning our wheels here, we can call a halt then, which brings me to my next point.
  2. Scope criteria - More directly on the topic at hand, I don't think an article count in the thousands should be necessary to decide that a portal can be created. That sounds like at least an order of magnitude too high, and would describe the current top-level portals. But as you all know, we have an entire hierarchy of smaller scope subportals (and dare I say sub-sub portals?) under those. The majority of older (pre-reboot) portals would have an article scope in the hundreds at most, and I think that sounds about right for a portal. I do believe that less than a hundred articles is a bit on the slim side, (re: recent MfDs) and while I know the topic area can grow, that's why we have WP:WTAF. Portals are so easy to create now, we can always not make a tiny one now, and come back when it's ready to be created. Put it on a "future portals" list or something.
  3. View count - So far as I can tell, view count has never been a priority metric for any of Wikipedia's content, least of all portals. You cited some metrics from Portal links included via categories, which are themselves viewed orders of magnitude less frequently than their member articles. The second-level negative effect that would have on the linked portal views would be expected, IMHO. It doesn't help that portals are only allowed to have a link at the bottom of the article (like many other types of non-article content), meaning that the majority of readers who don't read our sometimes overly-long articles to the end might never have seen them in the first place. Even if they are only in the dozens, if those handful of readers were able to find what they needed and walk away with a better understanding of the topic, then the portal has served its purpose.
  4. Role of portals - Portals are significantly more than "fancy navboxes", and while tiny-scoped portals can seem that way, the larger ones provide much more than that. You are correct that the primary purpose of a portal is to aid the reader in navigating a topic, but that is only half their function. See WP:CLNT, which covers this nicely, along with how they coexist despite their overlapping purpose. Categories and navboxes (and even lists and outlines) don't do much more than provide a structured list of links to the reader, and leave them to fend for themselves and figure things out on their own. We have smart readers, so I'm sure they manage that just fine, however, portals can go that extra mile to present the content in a way that allows the reader to engage with the topic in a more interactive fashion (The Transhumanist has written a novel on this already, so I won't go further here.) This also includes drawing the reader in as a potential editor by encouraging them to contribute and improve the topic area, both here and on sister projects. That last part cannot be discounted as immaterial or irrelevant.
This ended up being a wall of text anyway, it seems. All that aside, the actual criteria still needs to be written, which seems to be developing in the thread above this one. Your third criteria for an approval process, was brought up before, but the discussion didn't get very far. Perhaps it should be revisited. — AfroThundr (u · t · c) 03:18, 27 September 2018 (UTC)
  1. New portals you at least agree on a slowdown, so we are not far apart on this. However, I don't see evidence for a consensus anywhere on what is a "top-level portal" (e.g. where in this tree: Science → biology → zoology → Mammalogy → Primatology → Hylobatidae → Gibbons) ... nor any consensus that the existing set of higher level portals is inadequate. The point was not central at the recent RFC, so not assessed by the closer ... but there were a lot of voices saying that we need only a subset of the current top ones.
  2. Scope criteria as I expected, we disagree on that. But if we are going to restrict portals to higher level topics, then the count will be no barrier ... and I have yet to see any evidence of a consensus for micro-portals. Remember, there is a finite number of editors ready to maintain these portals. The more portals we have, the more that manitenance effort is diluted. I am arguing for fewer and better, 'cos it seems to me that some editors here just count numbers and ignore quality, utility nad usage.
  3. View count Portals are not content. Repeat after me: portals are not content. They are a navigational aid. The more navigational aids exist, they more they each decline in utitly, as happens when a road has too many signs: the crucial info is lost in the clutter. What exactly is the purpose in creating hundreds of hardly-ever -used portals?
  4. Role of portals. We agree on the utility of large portals. But most of their features are useful only on larger sets; in small sets, they are just alt-navboxes and are little used. An unread portal won't draw in editors to improve topics.
Remember, we recently had ~150 editors willing to TNT the whole lot; they lost that debate because a significant swing vote likes a subset of portals, while acknowledging that most of them are pointless. If this project doesn't do a fundamental rethink and focus on quality rather than quantity, then a proposal for a mass cull stands a good chance of gaining community consensus.
The drive-by-portal-making-bot-editor is shaping up to be the poster child for such a cull. Either this project applies some brakes, or the brakes will be applied from outside ... and in my 12 years of experience on en.wp, I have repeatedly seen that when the community decides that a project lacks self-discipline, it can react quite harshly. That WP:ENDPORTALS RFC should be taken as a last warning about community patience. --BrownHairedGirl (talk) • (contribs) 04:09, 27 September 2018 (UTC)
  • BrownHairedGirl, Some responses to your points above:
    1. New portals:Your question on which is a top level portal with an example tree: There are two ways of looking at this. The top level portal in that tree is obviously Science, but Science would be a subportal of All knowledge, so I guess that All knowledge is The top level.
  1. Scope criteria:The whole point of the new model portal is that it is largely self-updating as far as content goes. maintenance is restricted to updating the collection of templates used as and when new ones become available. This is experimental, but developing relatively quickly, thanks to several skilled coders' input.
  2. View count. We cheerfully join your chorus that portals are not content, You are preaching to the choir on this point. If you take a close look at the new model portals you will see that they contain on a first approximation, no unique content. They display content from mainspace in a different way, one which we hope will be useful to a significant number of readers. Whether editors ever use them is not important. We editors who have been here for several years know how to find content through the occult and arcane byways of Wikipedia, and of course the ubiquitous search functions, when we know what we are looking for. The portals should be a relatively reader-friendly system to find out more about a topic of interest, without presupposing a level of skill or requiring the reader to know what they are looking for by name. We are still working on this, I know it is imperfect. On the other hand, I spend a bit of time clicking on the list of one page portals as a sort of QA check, and report any bugs I find, but often find myself down the rabbit hole. Not everone's cup of tea, but I find them sufficiently engaging, particularly on topics I would not normally think of reading.
  3. Role of portals: We are exploring the role of portals. One of the things we are exploring is the effect of greater visibility, as that which cannot be seen is unlikely to be used. Hiding portals where no one sees them makes them unuseful.
I assume that the warning in your conclusion is just that, and not a veiled threat, which some may read into it. You may wish to clarify.
In conclusion, a question for you. What harm are the current portals doing? On what evidence is this analysis or opinion based? Bear in mind that they are not in mainspace.
BrownHairedGirl, One of the results of that is that there are now 393,762 links to Portal:Years ... but it still has a 90-day average of only 16 pageviews per day. The conclusion of obvious: promotion has not helped, and readers don't want that portal.. The conclusion is not obvious to me fron the results as quoted. Two questions immediately spring to mind: Did the readers notice the links, and if they did not, why not? If they did not notice the links, they cannot actively not want that portal, as they would be ignorant of it's existance. If they did notice the link, can we draw conclusions about their wanting the portal if they did not click it to see what it is. Can we assume that they know what is at the other end? Has anyone asked them? Of course it is possible that most readers would never use a portal even if they knew exactly what it was, but most readers do not visit most Wikipedia articles. How do we decide what is worth having? For articles it is the notability criteria. For portals it may depend on the overhead. A trivially easy to create and maintain portal which occupies very little storage in the database, and only really exists when someone looks at it is not a very large overhead. That is one of the targets we are working towards. We seem to be getting there. Is 16 pageviews per day for a low overhead portal actually a problem? Cheers, · · · Peter (Southwood) (talk): 07:47, 27 September 2018 (UTC)
I also endorse AfroThundr's "wall of text" response above. In most cases I could not have put it better myself (at least not without some hard work and a few false starts). Cheers, · · · Peter (Southwood) (talk): 08:47, 27 September 2018 (UTC)
@Pbsouthwood: First, you ask if I am making a threat. Answer: I have described what I see as a problem, and what I think should be done. I believe that there are already far too many portals, and that there has been a recent spree of trivia. There is clearly a v difft view among many project participants, and since several of them popped up at MFDs to say that there should be no deletions without guidelines, I want to see an RFC to set some guidelines on thresholds. I honestly believe that those posting so far have been ignoring the widespread disdain for portal-spam and micro-portals, and that this is a foolish position to take. There is no threat; just a promise that one way or another there will be an RFC on this, and a plea to project members to engage with why so may editors supported a TNT option rather than bury their heads in the sand of groupthink.
The overhead is not primarily in server load; per WP:SERVERLOAD we are generally encouraged to assume that any server load we are technically permitted to generate is fine. The overhead is two-fold: a) maintenance (more pages for editors to monitor); b) navigational. The second is my main concern: a portal by its nature promises a gateway to a large collection, and if it offers only a shelf-full it will disappoint readers who may thereby be less inclined to visit other portals. Such micro-portals will also need pointers from elsewhere, whether articles or categories, which means adding distracting and pointless signposting.
You ask is 16 pageviews per day for a low overhead portal actually a problem? Yes it is, because even aside from the monitoring load, that 16-a-day Portal: Queen (band) is signposted from 489 pages. That's 489 signposts to an almost-entirely unwanted destination. It is navigational clutter, and one the key aspects of effective navigational design is avoidance of clutter. That's why motorway signposts do not signal every village within reach and why sites such as Google and gov.uk use radically decluttered layouts. --BrownHairedGirl (talk) • (contribs) 10:27, 27 September 2018 (UTC)
BrownHairedGirl, I suggested you might want to clarify, thanks for doing so. I shall clarify my position a little too.
  • I don't believe there is such a thing as "Too many portals" per se. Too many inadequate or poor quality portals, or too many portals that don't serve a sufficiently useful purpose, sure. That can happen even if there are "not enough" portals, should that be a thing.
  • I am entirely in favour of sorting out a guideline for portal creation and portal deletion. As long as it is sufficiently flexible to work in an environment of fairly rapid change, and does not stop people from improving the encyclopaedia with new ideas that might be better. An RfC is the standard way to do this, so no problems there either. It looks like the time is about right. Bold - Revert - Discuss: TTH was bold, you applied the equivalent of revert, we are now discussing. This is good. This project is generally a friendly space for discussion, and we can usually come to an acceptable compromise.
  • Welcome to the project discussion pages, you can help us with alternative views. We are generally enthusiastic about some or other aspects of portals, or we would not be in the project. A bit of wider perspective can be useful.
  • I am glad that you don't see maintenance as a major problem, because almost all of our efforts go into minimising that.
  • A portal promises a gateway to content on the topic. Where does it promise a large collection? Sometimes only a small collection exists, and I agree that there is a lower limit of usefulness, but I don't claim to know what it is. I suspect it varies by topic and even by user.
  • If there are 489 articles within the scope of Portal:Queen (band) then I am inclined to think that 489 signposts is not excessive. If they are from pages not part of the topic, then I agree with your point, while noting that there may be even more in-line links to the article Queen (band) scattered through the encyclopedia. I also don't see what that the 16-a-day have to do with this, or where this clutter is that you don't like.
  • If there is widespread disdain for portal-spam and micro-portals where is it expressed? Cheers, · · · Peter (Southwood) (talk): 11:35, 27 September 2018 (UTC)
Pbsouthwood, Some quick replies to those points.
  • You don't believe there is such a thing as "Too many portals" per se. I disagree: only 7 of the 8 portals linked on the front page get over 1000 hits per day. Nearly all of the rest get damn all readership. They are not content; they are navigational devices, and an unused navigatiional signpost is a cluttering distrucation. I say purge the stacks of barely-used ones
  • You say A portal promises a gateway to content on the topic. Where does it promise a large collection? It used to do so at the top of WP:PORTAL, as you can see in the version of 2 May 2016, which was unchnaged for two years. The sceind para read "Please bear in mind that portals should be about broad subject areas, which are likely to attract large numbers of interested readers and portal maintainers".
    That guidance was removed[11] on 23 May 2018 by The Transhumanist, whose edit summary simple says "update". No evidence was offered of a broad community consenus for such a major change of scope to an entire namespace. So I have reverted to the long-term stable version Discussion at Wikipedia talk:Portal guidelines#Current_version_of_the_guidelines.
  • If there are 489 articles within the scope of Portal:Queen (band) then I am inclined to think that 489 signposts is not excessive. The 16-views-per-day for the portal demonstrates that they are signposts which readers do not want to use (16 is only 0.15% of he views of the main article). Unusused and unwanted signposts are clutter, whether on a road or on a webpage.
  • If there is "widespread disdain for portal-spam and micro-portals where is it expressed?}}. Answer: in the lede of WP:PORTAL ("Please bear in mind that portals should be about broad subject areas, which are likely to attract large numbers of interested readers and portal maintainers") and in plenty of comments at WP:ENDPORTALS
I am sorry to say that my discovery of the undisclosed unilateral rewriting by TTH of the WP:PORTAL guidelines has confirmed my fear that TTH has not been acting in good faith. I would also like other editors to clarify whether they were aware of this change, and if so why they did not mention it in discussion.
Now that the unilateralism has been reverted, we can focus on clarifying the threshold set there, rather than working from first principles ... unless of course TTH or anyone else wants to open an RFC proposing the radical wideniung of scope. --BrownHairedGirl (talk) • (contribs) 00:55, 28 September 2018 (UTC)
Actually, it is BHG who has violated guidelines, not me. See #Response to BHG's accusations and guideline reversion. Thank you.    — The Transhumanist   12:37, 28 September 2018 (UTC)

Metrics request

Tracked in Phabricator
Task T205681

@Pbsouthwood, BrownHairedGirl, The Transhumanist, and Waggers: I don't have time to respond to the latest discussion right now, I'm about to submit a phabricator ticket to ask the analytics team about some of this. Here's what I currently have. Feel free to add to or modify the list. I want to get a solid description drafted instead of tweaking it on phabricator. I'll submit it a bit later. — AfroThundr (u · t · c) 13:21, 27 September 2018 (UTC)

Extended content

T205681: Metrics request on portal namespace usage

Tag: Analytics
CC: Pbsouthwood, BrownHairedGirl

In preparation for a new RfC on enwiki regarding new guidelines for the Portal system, we would like to gain additional insight into how much the current portal system is currently used. We can get easy stuff like view count already, but that does not take into account other more detailed aspects. Such as:

  • How many people clicked on a portal link from an article, or a category?
    • Which articles, and which categories generated the highest traffic?
  • How many people followed through to another article from the portal, or just closed the tab?
    • Which articles and portals had the highest engagement? (useful for replicating their success)
  • How many people even scroll to the bottom of the article and even had the opportunity to notice the portal link?
    • About what article size tends to result in zero portal link visibility?

I'm not sure how detailed the analytics are the WMF is currently collecting, so some of this may not be plausible at this time. I'm basing this off of the various studies I've seen run, like the recent citation usage study m:Research:Characterizing Wikipedia Citation Usage. Granted, that is a more involved example, and I'm not asking you to make schema changes to facilitate this or anything.

This is now tracked as T205681. — AfroThundr (u · t · c) 01:34, 28 September 2018 (UTC)

Back to the topic

Let's try to keep this discussion on topic, and that topic is: how do we define what is a sufficient scope for a portal to exist? Discussions about the purpose of portals, repeating the "delete the whole namespace" RfC discussion all over again, talk of page views as if this were a commercial, advertising-driven website, or the behaviour of individual editors and whether or not they should stop creating portals are all distractions from that. They might be important discussions to be had elsewhere but let's try to keep this thread on track.

There will always need to be a bit of leeway in any such guidance. For example, if there is a large, notable topic that doesn't have many articles written about it yet, it's still a large, notable topic and therefore suitable for a portal. So the blunt instrument of counting selected articles doesn't cut the mustard (a mixed metaphor that works surprisingly well).

What's interesting about the recent MfD spree is the pattern behind it: it seems The Transhumanist went on a portal creation spree based on the notion that if there is a navbox, then the topic is sufficiently wide in scope to have a portal. Then BrownHairedGirl went on a deletion spree, nominating portals for deletion if they didn't have a corresponding category. So maybe there's something about the existence of a navbox and/or a category for a topic that could form the basis of some guidance. Not as fundamental criteria, but as an indication of whether a topic meets whatever criteria we do decide upon.

Something else we need to consider is that the new format of portals is much more lightweight in terms of the effort needed to create and maintain them, and indeed the space they take up in the Wikipedia database. As such I would argue that the bar for inclusion can be set much lower than it would have been for the old-style, manual maintenance, lots-of-subpages portals. WaggersTALK 08:06, 27 September 2018 (UTC)

Funny thing that. I have been suggesting that the existence of both a navbox and a category of same topic scope, and preferably the same or very similar title, are fairly indicative of a portal being appropriate, and have suggested that if the category does not exist and the portal should exist, then the category should be created. This helps categorisation too, which is also a gain for the whole system. So I am with you on this one.
I will go further, and generally agree on your whole post. · · · Peter (Southwood) (talk): 09:30, 27 September 2018 (UTC)
I've found that creating new portals helps identify categories that need creation. In many cases there are subcategories already in place, that lack a parent category which the portal identifies. This happens a lot with singers and bands. There will be categories for their singles and albums, but not one for the singer or band itself.    — The Transhumanist   09:51, 27 September 2018 (UTC)
I've just taken a good look at WP:CAT since it seems to make sense that we use similar criteria for creating portals as we do for creating categories. So what are the minimum criteria for creating categories? Perhaps surprisingly, there don't seem to be any listed at WP:CAT. Users are encouraged to create any categories they think are appropriate provided they are appropriately named and have a parent category. A similar approach for portals doesn't seem unreasonable to me. WaggersTALK 10:05, 27 September 2018 (UTC)
That sounds like a good idea. It allows editors the freedom of not having to get a portal approved by other editors. However (like categories and them being empty consitutes a speedy deletion), I still feel that keeping the speedy deletion for a portal without a substantional base is a good idea. Dreamy Jazz 🎷 talk to me | my contributions 11:46, 27 September 2018 (UTC)
Yes, I don't think anyone is suggesting getting rid of WP:P2. WaggersTALK 13:34, 27 September 2018 (UTC)

Oh dear . Pile of ABF there, @Waggers.

First, I did not go on a deletion spree and I did not go on a deletion spree, nominating portals for deletion if they didn't have a corresponding category. What I did do was in the course of cleaning up Special:WantedCategories I found a series of redlinked cats which consisted of portals placed in non-existent eponymous categories. In such cases I found that these portals were all populated by 
Category:{{PAGENAME}}
, and that they were mostly categories which would not normally be created, or deleted if they existed, such as eponymous categories for musicians and bands. This was odd; having processed tens of thousands of redlinked cats in the last year or so, I had rarely encountered portals. I was surprised to see the use of a poorly-automated category entry like this, and I noticed little effort made at other categorisation. Whatever these were was clearly rapid-fire templating. So I began scrutinising the portals, and when I saw the narrow scope of some of them I began to do what I do when I encounter other apparently inappropriate content in this process: nominate them for deletion. I was shocked by how many such micro-portals were appearing, and by he bizarre reaction of TTH to my first nomination.

In no case did I MFD a portal because it lacked category; that is no grounds for deletion. The redlinked category was solely how I encountered them.

The second point of misrepresentation is that neither I nor anyone else is trying to revive the delete-all-portals proposal. That was clearly rejected.

However, there was a lot of support in that discussion for the idea that there are too many portals. And as I have repeatedly noted, this project has gone in the other direction, creating hundreds of new portals. I do not believe that there is community consensus to do so, and esp not to create portals on such narrow topics. Waggers and others argue at MFD that there should be guidance on which portals are appropriate, and that deletion decisions should be based on that. This is the discussion I also want to have, and since Waggers sought a moratorium on MFDs then it's sensible for everyone to take a break from both creation and deletion while we try to discuss how e frame an RFC on criteria.

Thirdly, there are far more constraints on categories than Waggers sates. See for example WP:OCAT, and the stream of catefory deletion and merger discusisoins at WP:CFD.

Anyway, back on topic after correcting Waggers misrepresentations.

I get that Waggers and Pbsouthwood and TTH want a v low bar (if any) for portals. I hope it is now clear that I want a higher one. We have all made our basic positions clear, and I see a huge gap.

So the principles of this guidance needs to be settled by an RFC, not simply by members of this project. Does anyone in this project actually want o work with me on drafting such an RFC? Or do you just want to form a WP:LOCALCON amongst project members? --BrownHairedGirl (talk) • (contribs) 19:55, 27 September 2018 (UTC)

I'm no expert on RFC-drafting, but I'm willing to work on the process and criteria for setting a bar for portals. There has to be a bar at some level, or anyone could create an atrociously-built portal or a portal about every village in the world. I don't think anyone here would defend those. So could we not try to find an interim solution first, before going to RFC where views are likely to polarise further? Here are some thoughts:
We agree a bar, ideally mid-way between the opposing positions for future portals
The bar isn't retrospective i.e. we don't use that to mass delete existing portals
We only create new portals that meet the new criteria
We run with the new criteria for six months and then review them
We focus our effort on a) improving existing portals and b) creating those new portals considered to be 'top level'. Someone's already posted a pretty reasonable-looking list. Bermicourt (talk) 21:35, 27 September 2018 (UTC)
@Bermicourt: thanks for that prompt and constructive response.
I agree that there should be a bar somewhere. I have my own prefs on the where, but I think the worst outcome is no bar.
However, I think that the gap between the two views is to great for any sort of trial-compromise position to be helpful. At one extreme we have those such as TTH who sets the bar so low that we could have many tens of thousands of portals without ever falling below the threshold. On the other hand, there are those like me who advocate a massive cull in the number of existig portals, reducing the number to below 100. That's nearly three orders of magnitude of difference, and a comprmise across such a big gap satisfoes nobody. As a trial it would tell us little or nothing to inform us of the merits of either propsoal. We need to choose a broad direction.
Both extremes clearly have a lot of support, so we need to seek a community consensus on which broad direction to take. The mechanism for that is an RFC, which may be best done in more than one stage. Phase one, choose the many / fewer / v few options ... then in phase 2 decide how that threshold is defined (some or all of article counts/vital article asessments/pageviews/etc)
I will create a new section below with a first draft of these options. --BrownHairedGirl (talk) • (contribs) 22:40, 27 September 2018 (UTC)
BrownHairedGirl, I can't find the new section with draft. Possibly you have not started it yet. If/when you do, please mention the header here. For the record, I see all these options as temporary until the quantum portal (generated on demand from a template or script, and does not exist unless someone is observing it) is available, at which point the guidelines may become largely redundant, and permanent portals may become showcases built by enthusiasts again. In the meanwhile I prefer a relatively wide scope so experimentation can be more effective. Cheers, · · · Peter (Southwood) (talk): 08:37, 28 September 2018 (UTC)
While there is a large gap between the camps, I believe we could still come up with a workable compromise in the meantime. While community consensus is the ultimate deciding factor, it helps if that consensus can be built on an informed opinion, backed by evidence and experiment data. To that end, a trial could still be useful. Otherwise, we'll all be guessing in the dark as to which solution would be best. Should we not make the best decision in the upcoming RfC, it would take yet another RfC to change it again, by then I think the community would be getting a bit tired of Portal RfCs, regardless of which side of the argument they support. If possible, I would like to do it right the first (second?) time. — AfroThundr (u · t · c) 14:33, 30 September 2018 (UTC)
@AfroThundr3007730: I believe that there are currently over 3000 portals, with a wide variation in scope. It seems to me that any data needed to develop an informed consensus at RFC can be drawn from that existing set.
Do you believe that there are some gaps in that set, gaps which should be filled on a trial basis to allow analysis? --BrownHairedGirl (talk) • (contribs) 14:45, 30 September 2018 (UTC)
The portals that correspond to level 2 vital articles would be a good test pool, possibly level 3 as well. The list is posted on WP:WPPORT#Fill in the gaps and below at #Portal Wish List. I and several others have suggested we migrate portal creation efforts from the more low-level portals to these higher priority ones, working our way down those lists. If these important topics aren't indicative of a good subject for a portal, then I'm not sure what else would be. The Level 2 portals could serve as the "poster child" for the namespace, alongside the top-level and the (historically) featured portals. Once they are all built and linked in place, we could gather better data from site analytics to better gauge reader interaction. This also ties into the #Metrics request I made earlier. — AfroThundr (u · t · c) 15:24, 30 September 2018 (UTC)
@AfroThundr3007730: I may be looking in the wrong place, but I see a significant number of existing portals at each of those levels. Dozens of them in WP:WikiProject Portals/Vital portals level 2 and dozens in WP:WikiProject Portals/Vital portals level 3.
It seems to me that this set of existing portals is way more than sufficient to get statistically valid data from. Creating more such portals now does not seem to me to be an exercise in building a valid test sample; it looks to me like pre-emption of consenus-building. --BrownHairedGirl (talk) • (contribs) 15:46, 30 September 2018 (UTC)
Re: ABF and the duck test:
People have a tendency to call things as they see them. If a thing looks like a deletion spree it is likely to be called that by someone who is not in possession of the full background. Calling their description an assumption of bad faith does not take into account that they do not have the full picture. It is an error we all make at times, but usually not conducive to civil interaction. I think we here are all trying to build the encyclopedia. It is an evolutionary process as it has not been done this way before. Experiments are not just healthy, they are necessary to allow a robust set of characteristics which can stand up to unexpected external pressures. If there are three optional ways a thing can be done, and for some reason one becomes impracticable, the other two may allow us to survive. Even when all are workable, we cannot predict which may work best after unforeseen changes, and there will always be unforeseen changes. The most dangerous strategy is stagnation. On the other hand unchecked development can sometimes also be detrimental, and needs to be tested against reality. Let us make a virtue of necessity and use this to come up with something that works. · · · Peter (Southwood) (talk): 08:54, 28 September 2018 (UTC)
Sidebar #1: Creation vs deletion criteria

"Creation criteria" is potentially synonymous with "deletion criteria". What happens to existing portals that don't meet newly established creation criteria? If the answer is "deletion", then that means the creation criteria discussion is in fact a deletion discussion.    — The Transhumanist   10:15, 27 September 2018 (UTC)

  • Since creation is becoming easier, this is not a big deal. Sometimes the post construction checks don't pick up all the problems and a lemon slips through under the radar. We should be glad to have more eyes checking, as if we identify the problems, we can fix them, and recreate the portal another day when the tools are more robust. If a topic really isn't ready for a portal, it is no loss to delete it until it is ready. · · · Peter (Southwood) (talk): 13:26, 27 September 2018 (UTC)
(edit conflict)No, deletion would not be automatic, there would still need to be discussion around each case. Yes, a portal that fails to meet whatever criteria we agree would be more likely to be deleted - but the discussion would still need to take place first, unless the portal falls within the remit of WP:P1 or WP:P2, and if there's a good case for making an exception to the new creation guidelines, that would be the place to argue it. WaggersTALK 13:32, 27 September 2018 (UTC)
  • (edit conflict) Remember that if it had not been for the RfC for deletion of the whole portal system we would not be here improving portals so effectively, and they might just have fizzled out quietly and unnoticed. That opposition had the effect of revitalising the project. For evolution to work effectively, there must be some standard of fitness to pass or some form of competition. For portals to become robust, a bit of external pressure and selective culling can improve the herd. · · · Peter (Southwood) (talk): 13:40, 27 September 2018 (UTC)
  • It would also be less likely for portals to be nominated for deletion if we all had a better idea of where the bar is, as we would not create them unless fairly sure they would make it. · · · Peter (Southwood) (talk): 13:46, 27 September 2018 (UTC)
It thrills me to witness such independent thinking on the team. I hadn't thought of the points you all raised. I believe portals are in good hands.    — The Transhumanist   21:26, 27 September 2018 (UTC)
@Pbsouthwood: We have a pretty good sampling of portals right now. I would be interested in your take on the current set of portals. Which ones pass muster in their current state, and which ones need to be improved to meet acceptability. We can use currently existing portals as examples of what we are talking about in the whole criteria discussion.    — The Transhumanist   21:26, 27 September 2018 (UTC)

Any criteria for what is an appropriate portal will obviously apply both ways. A portal which exceeds the criteria would usually be kept in a deletion discussion, and those which fall below it would usually deleted -- just as happens in AFDs which consider the notability of a topic. In any such debate, there is scope for editorial discretion.

WP:P1 & WP:P2 are criteria for speedy deletion, i.e. without a discussion. Speedy deletion is reserved for extreme cases which clearly fall so far outside community norms that the community gives admins discretion to delete them without discussion. So far, I see no reason to consider changing them.

I advocate some form of pre-creation discussion, at least for a while, because it means that the viability of a portal can be assessed before an editor puts time and effort into creating it. That saves everyone a lot of work until guidelines have stabilised and clarified. The utility of a pre-creation discussion depends in large part on how high the bar is set: if the criteria are almost-anything-goes, then discussion would in most cases be pointless.

If the criteria remain as per the Portal guidelines (now restored to their long-term stable version), or something tighter, then a discussion would be both useful and infrequent. I suggested a "negative process" where creation proceeds unless there is objection, and objections trigger a discussion whih requires a consenus. Therefore an uncontested proposal does not require others to post a "support". --BrownHairedGirl (talk) • (contribs) 01:25, 28 September 2018 (UTC)

@Pbsouthwood, Waggers, and BrownHairedGirl:
Since the restored version sets the criteria at "around 20 articles" (down from 30 as of May 2009), it will do until a new consensus is formed.    — The Transhumanist   19:50, 4 October 2018 (UTC)
Sidebar #2: Restoration of original portal guidelines

I just spotted today that on 23 May 2018, The Transhumanist substantially rewrote WP:PORTAL.[12].

This rewrite replaced a version which had been stable for two years, since the version of 2 . I have restored the stable version, for reasons explained below.

One of the many changes made was to the lede. The stable version read:

Please bear in mind that portals should be about broad subject areas, which are likely to attract large numbers of interested readers and portal maintainers

However, TTH's rewrite removed the stipulation of broad scope, and both of those criteria, i.e. readers and maintainers. The edit summary used was simply "update", which is so vague that it is a clear breach of WP:SUMMARYNO. It is wholly inadequate in this case.

TTH's change radically redefined the purpose of an entire en.nwp namespace. That is an extraordinarily big change, which should have been the subject of a well-advertised RFC. However, I have found no evidence even of this change being the subject of a standalone discussion on a community-wide noticeboard, let alone assessed in a properly-conducted RFC.

I am also very disappointed that in our extensive discussions both on this page and elsewhere, at no point has TTH mentioned that they made such a unilateral rewrite. The effect is sneaky and underhand; I cannot judge whether the sneakiness was intentional or a lack of WP:COMPETENCE, but either way it is disgraceful.

I know that TTH has strong views on why they believe that portals should be chosen on a very different basis to the stable community consensus. However, the way to make such a change is to propose it a WP:RFC. I strongly advise TTH not to simply reinstate the unilateral rewrite.

Unless and until such an RFC is opened, the place to discuss the substantive merits of the guidelines is at WT:Portal_guidelines#Current_version_of_the_guidelines. Guidelines such as this belong to the whole community, not to any one WikiProject, so revisions should be discussed centrally rather than on a project's pages.--BrownHairedGirl (talk) • (contribs) 00:43, 28 September 2018 (UTC)

To what seems to me a large extent, TTH's rewrite of the portal guidelines was not incompatible with the actual process at the time, so could be considered descriptive rather than prescriptive. As in other cases mentioned on this page, not being aware of the larger picture may lead to duck calling.
Discussions often happen where they are started. There may be no particular plan behind this. If someone notices that they are in the wrong place the discussion may be moved, otherwise it is likely to stay, and spin off sub-discussions, also in the same place. No special motivations are necessarily involved. Cheers, · · · Peter (Southwood) (talk): 09:21, 28 September 2018 (UTC)
@Pbsouthwood: Thank you for your support and assumption of good faith. That means a lot to me.    — The Transhumanist   11:23, 28 September 2018 (UTC)
I call it as I see it. Sometimes there is no duck. · · · Peter (Southwood) (talk): 16:44, 28 September 2018 (UTC)

BHG stated above that I radically changed the purpose of an entire namespace. That is both exaggerated and bit melodramatic. Below, I've reposted the response I provided on the guideline's talk page. (The statement we were discussing was "Please bear in mind that portals should be about broad subject areas, which are likely to attract large numbers of interested readers and portal maintainers."):

The purpose of the portal namespace was changed long ago, by the very people who have built portals, from the moment that statement was written. Editors build portals on the subjects that interest them (the same as with articles), rather than on the traffic prospects of a subject, and except for the few portals listed on the Main Page, always have. This practice is therefore very well established. (See WP:PGCHANGE).
In addition to this, the lead statement itself is in error, as portals by their very nature do not attract large numbers of interested readers or portal maintainers. That's because portal titles generally do not show up in external searches of their subject names, which is where large numbers of readers to pages come from. That is, "Portal:Fish" doesn't not come up when you search for "Fish". An external search will show a portal if the word "portal" is included in the search term, but googlers don't typically enter that term. Portals primarily receive internal traffic from within Wikipedia itself, via the internal links that readers click on. They always have.
And while "broad" isn't defined in the lead, guidance for the scope of portals is provided further down the page, where it states the number of articles to be included to be "about 20", a guideline that has been in place since May 2009.    — The Transhumanist   18:36, 5 October 2018 (UTC)

Response to BHG's accusations and guideline reversion

Another RfC wasn't needed, because we had just gone through one that established community consensus concerning portals. Its closing statement was "There exists a strong consensus against deleting or even deprecating portals at this time." Based on the outcome of the WP:ENDPORTALS RfC, I updated the guideline page to reflect the community consensus and the current reality of portals.

This approach is in concordance with WP:PGCHANGE and WP:PGBOLD.

WP:PGCHANGE states:

Policies and guidelines can be edited like any other Wikipedia page. It is not strictly necessary to discuss changes or to obtain written documentation of a consensus in advance. However, because policies and guidelines are sensitive and complex, users should take care over any edits, to be sure they are faithfully reflecting the community's view and to be sure that they are not accidentally introducing new sources of error or confusion.

Because Wikipedia practice exists in the community through consensus, editing a policy/guideline/essay page does not in itself imply an immediate change to accepted practice. It is, naturally, bad practice to recommend a rejected practice on a policy or guideline page. To update best practices, you may change the practice directly (you are permitted to deviate from practice for the purposes of such change) and/or set about building widespread consensus for your change or implementation through discussion. When such a change is accepted, you can then edit the page to reflect the new situation.

Concerning substantive changes to a guideline, WP:PGBOLD states:

Or be bold. The older but still valid method is to boldly edit the page. Bold editors of policy and guideline pages are strongly encouraged to follow WP:1RR or WP:0RR standards. Although most editors find advance discussion, especially at well-developed pages, very helpful, directly editing these pages is permitted by Wikipedia's policies. Consequently, you should not remove any change solely on the grounds that there was no formal discussion indicating consensus for the change before it was made. Instead, you should give a substantive reason for challenging it and, if one hasn't already been started, open a discussion to identify the community's current views.

Editing a policy to support your own argument in an active discussion may be seen as gaming the system, especially if you do not disclose your involvement in the argument when making the edits.

The lead of the guideline before I changed it was "Please bear in mind that portals should be about broad subject areas, which are likely to attract large numbers of interested readers and portal maintainers. Do not create a portal if you do not intend to assist in its regular maintenance." That was made a part of the guideline on August 3rd, 2006 in this edit https://wiki.riteme.site/w/index.php?title=Wikipedia:Portal_guidelines&diff=prev&oldid=67490184 . Note that broadness wasn't defined, but it was assumed that any portal on a broad subject would attract large numbers. [Editing note, 10-04-2018: I was mistaken about broadness not being defined. Further down the page it set the bar at "about 20 articles", established as of May 02, 2009 in this edit: https://wiki.riteme.site/w/index.php?title=Wikipedia:Portal_guidelines&diff=prev&oldid=287431020]

Except for a small percentage of portals, that guideline has never been followed [editing note, 10-04-2018: many of the portals from the set that existed in April 2018 have fewer than 20 articles included. Portal:Mathematics, a subject of thousands or subtopics, only has 40 articles, and of those displays only a single 1.]. Portals for the most part, do not, and have never attracted particularly large numbers of readers; and at the time of the RFC, all but about 100 of them were completely abandoned. Large numbers of maintainers never materialized; usually a person made a portal on whatever they were interested in, and then never returned. Or they lost interest over time and faded away. The odd assortment of portals exhibited a wide-range of scope.

Yet, the community decided to keep them all. "There exists a strong consensus against deleting or even deprecating portals at this time." Even though many weren't particularly broad, even though they weren't well read, and even though they lacked active maintainers.

So I removed the outdated statement from 2006. It hadn't represented standard practice in many years, and no longer represented community consensus.

The rest of the guideline was also out of date and lacking in detail about portals, which was spread out in haphazzard fashion among multiple pages. I merged relevant material into it from the WikiProject page, and the entirety of Wikipedia:Portal (the main information page on portals). The record of all these edits are in the edit history of the guideline page, so you can see the progression of development. I also revised explanations to reflect the current way portals were designed. The material has been proofread and refined by other portal-savy editors since, and accurately reflects the current state of affairs and practices concerning portals.

Now BHG is being even more bold than I was, has reverted the work of more than one editor, but is grasping at straws, hanging on to the old lead statement as if the RfC never happened. She has violated this part of WP:PGBOLD:

Consequently, you should not remove any change solely on the grounds that there was no formal discussion indicating consensus for the change before it was made. Instead, you should give a substantive reason for challenging it and, if one hasn't already been started, open a discussion to identify the community's current views.

The guideline needs to be restored to the version reflecting the decision of the community in the WP:ENDPORTALS RfC and current practice on portals. Sincerely,    — The Transhumanist   11:39, 28 September 2018 (UTC)

The text is still in the history. Restoration is not urgent. Getting an acceptable compromise by way of a usable set of creation criteria is better use of time at the moment. What we have here may just be a failure to communicate. Lets take a look at common ground for a start. I get the impression that both BHG and TTH are quite deeply involved in navigation of the site. Well, surprise, so am I. We are on the same side, we must have common ground. In a year or two this will be history that few will bother to read, so lets try to get where we are going with the least stick waving. As my cousin used to say, I'm an arsehole, you're an arsehole, now that we have that settled lets get down to work. A bit crude perhaps, but it gets the message across. And no, I am not saying that either of you are arseholes, it is just an illustrative quote, I actually believe that both of you are acting mostly in good faith and sincerely, and can both make productive and valuable contributions here. If you feel the need, vent at me and then lets get to work. Cheers, · · · Peter (Southwood) (talk): 17:01, 28 September 2018 (UTC)
Are you sure that is a better use of your time? You've witnessed an editor use intimidation tactics to push an agenda and disrupt the activities of an entire WikiProject, violating WP:AGF, WP:CIVIL, WP:BULLY (WP:POV railroad, False accusations), and Wikipedia:No personal attacks. Are you going to simply let that continue?    — The Transhumanist   20:01, 28 September 2018 (UTC)
Well we can either take that to arbitration which will be lengthy, acrimonious and unlikely to succeed. BrownHairedGirl is an experienced editor and administrator who is very familiar with Wikipedia and may just have a point. It's always important to look for the "critic's kernel of truth" as Bill Hybels would say. Then we can have a dialogue. That there will be a dialogue is certain, because BHG will take this issue to the community for discussion. So we are bound to have to compromise in the end. I would prefer us to reach some sort of consensus without widening (and thus prolonging) the debate further. Even if we have to curtail the number of portals, we still have plenty to do. Bermicourt (talk) 21:02, 28 September 2018 (UTC)
Then I say take it to arbitration. There is no WP:SENIORITY and we are looking for the best ideas, rules, and the best way to make an encyclopedia here. There is no additional merit to any comment just because it comes from an experienced editor. And since it seems there is support toward a specific editor rather than toward the idea the editor has put forward, that to me calls for arbitration. One other thing... not exactly the greatest time to quote anything from Bill Hybles.--Paul McDonald (talk) 14:17, 29 September 2018 (UTC)
Very gun-ho, but that's just seeking a wider confrontation which we don't need. Of course, experienced editors and admins are worth hearing - that's just common sense. And I wondered if you'd fall into the trap of an ad hominem argument over Hybels. We should beware of shooting the messenger, who is just a human being like the rest of us, lol. Or we'll never learn from the experience of others. Bermicourt (talk) 14:48, 29 September 2018 (UTC)
I think you mean gung-ho.--Paul McDonald (talk) 15:02, 29 September 2018 (UTC)
Oh dear. Yet another irate wall of text from @The Transhumanist.
As I noted above, this is not the place for the substantive discussion. That belongs in a community noticeboard, not on a WikiProject page.
So I will restrict my response to noting that TTH wrote Based on the outcome of the WP:ENDPORTALS RfC, I updated the guideline page to reflect the community consensus and the current reality of portals.
Llemme quote in full the outcome of the WP:ENDPORTALS RfC "There exists a strong consensus against deleting or even deprecating portals at this time".
Nowhere in that one sentence does it say that there is a consensus to remove the restriction that "that portals should be about broad subject areas". The consensus was weighed solely as "do not delete them all."
The community was not asked to decide whether to remove any restriction on the scope of portals. So we simply do not know whether consensus has changed from the guideline which was stable for two years.
I note significant support at the RFC for reducing the number of portals. TTH believes there was support for expansion. But neither of us can say that there was a consensus for either change, because the RFC never tested it. (I was one of several editors who expressed regret at the binary nature of the RFC, but we were too late; it was as it was.)
TTH's verbose response consists mostly of arguments for change which should have been proposed at a followup RFC. That second RFC could have asked "now that portals are not all to be deleted, should we delete most/delete some/keep existing ones/create more/massively expand". But instead TTH yet again mistakes TTH's own view for a consensus. This is wearisome: one person's view is not a consensus for change, no matter good they believe their case to be.
I took a break after reverting the guideline, because after all the discussion about the thresholds for portals, I was frankly disgusted that nobody chose to mention that the guideline had been stealthily rewritten by the editor who went on a mass-creation spree. Maybe other editors were unaware of that rewrite, but TTH was aware and should have disclosed it at the MFDs and in the subsequent discussions on this page. So I took a break from this page, because I wanted to let my annoyance pass.
My views on that non-disclosure have been made clear, but that is done now ... and now we have a restored guideline which nobody is happy with (I think it is too loose, others think it is too tight) and which is clearly incompatible with the recent mass creation spree(s).
So the RFC I was proposing earlier now has a clear focus: to build a consensus on whether to retain the current "broad subject areas" guideline, or replace it with something else. I will start drafting tomorrow, and I hope that we will be able to agree on a smallish range of options to put to RFC, to hopefully build an explicit consensus, whatever that consensus may be. --BrownHairedGirl (talk) • (contribs) 00:51, 30 September 2018 (UTC)
BHG, please refrain from personal attacks.--Paul McDonald (talk) 01:10, 30 September 2018 (UTC)
@Paulmcdonald: Please read WP:No_personal_attacks#What_is_considered_to_be_a_personal_attack?, and please refrain from making unfounded allegations of personal attack.
I criticised the conduct of an editor, but I made no personal attack. --BrownHairedGirl (talk) • (contribs) 01:50, 30 September 2018 (UTC)
I see the comment "Yet another irate wall of text from @The Transhumanist" as a personal attack. It added zero value to the discussion and was a negative comment addressed to an individual by name. Let's keep the discussion about the matter at hand and not about individuals in the conversation.--Paul McDonald (talk) 13:28, 30 September 2018 (UTC)
@Paulmcdonald: I would find it easier to believe in your good intent if you had some reproach for the lastest irate wall of text directed me, rather than simply at my reply. --BrownHairedGirl (talk) • (contribs) 14:24, 30 September 2018 (UTC)
Not that this is in any way on topic, but I agree that some of the sidebar comments are unnecessary, not that they are particularly bad or anything. Also, both TTH and BHG tend to write long responses that some would classify as walls of text. Lots of us do. We have a lot to talk about, and this is a multifaceted subject that requires in-depth discussion. To gloss over the nuances would be doing an injustice to the portals we're here to curate, and to the community. So can we all just agree that walls of text are going to happen, and move on? — AfroThundr (u · t · c) 14:52, 30 September 2018 (UTC)
It might minimise disruption and show good faith all round if we could respect a couple of temporary guidelines until a proper RfC has concluded (or a few months have elapsed with no RfC outcome, let's say end of 2018):
  • Only create portals on the most important topics, i.e. those which would be a WP:SNOW "keep" at any hypothetical MfD.
  • Only nominate portals at MfD for being "too narrow" if they would be a WP:SNOW "delete". Poor quality portals may still be taken to MfD for other reasons, but it would be better to report them to this WikiProject for clean-up first.
Does that sound reasonable? Certes (talk) 11:23, 30 September 2018 (UTC)
@Certes: I agree that a moratorium is a good idea until a consensus is established (or clarified, depending on you see it).
However, I am wary of relying on editors to judge what might achieve a SNOW close, esp given the widely different understandings shown so far. It seems to me to be better to simply say no creations and no MFDs. --BrownHairedGirl (talk) • (contribs) 13:22, 30 September 2018 (UTC)
I would be fine with a pause on creation for the smaller type of portal until we have solid critera (the RfC). More important topics (re: Vital topics above) should still be ok, since I don't think there's significant argument against those in particular. I don't think we need to freeze an entire namespace until the RfC is done. — AfroThundr (u · t · c) 14:52, 30 September 2018 (UTC)
I do intend to present an argument for a low threshold. We clearly have different views on the likely response to that position, but what's the rush to create new portals?
TTH has repeatedly shown that a new portal can be created in less than 90 seconds, but an MFD takes way more editorial time than that when the time of each participant is added up.
The urgent task now is to establish a broad consensus. --BrownHairedGirl (talk) • (contribs) 15:36, 30 September 2018 (UTC)
I disagree that any task is "urgent" for as a general rule there is no deadline. I can agree that it is "important" -- I also disagree with the term "establish" consensus, as that implies building it up and can be considered by some to be votestacking. The task at hand really should be to determine the consensus, not to build it.--Paul McDonald (talk) 15:30, 1 October 2018 (UTC)
BHG, my first "wall of text" wasn't disruptive, as you posted, nor was my next one irate as you accused. Those 2 statements of yours were false accusations, and therefore fall under our no personal attack rule. You accused me of acting a certain way, when I wasn't. Please refrain from doing that. Thank you.    — The Transhumanist   17:10, 4 October 2018 (UTC)

@Paulmcdonald, BrownHairedGirl, AfroThundr3007730, Certes, Bermicourt, and Pbsouthwood:

Note that the present guideline, the one that BHG restored, sets a low-end for scope of "about 20 articles." It was changed from "about 30 articles" in May of 2009. BHG has been objecting to portals (via MfD) based on how many articles they display, such as Portal:Body piercing, which displayed 11 articles at the time she nominated it for deletion. Note that the guideline was referring to the pool from which a portal displays selected articles, because the main design up until last April only displayed a single article per selected section -- a portal's pool of excerpts has been stored as subpages, and in a great many cases, never reached 20, and represents the established practice - though the practice has changed for new and upgraded portals since then. Portal:Mathematics, by comparison, still only has a pool of 40 article excerpts, merely double the number mentioned in the guideline, which it displays one-at-a-time. Portal:Body piercing displayed 11-at-a-time, from a pool of 74. Now it displays all 74.

In order to change the "about 20 articles" guideline, will require a new consensus. Until then, we have the "about 20 articles" standard in place.

I hope the clarification helps. Sincerely,    — The Transhumanist   01:55, 5 October 2018 (UTC)
Sidebar #3: Portals approval department proposal (withdrawn)

Long ago, in a talk archive far, far away... We discussed the possibility of a formal (or semi-formal) portals approval process. I'm trucking out that discussion once more, since it was brought up earlier. For posterity, the discussion is posted below.

On random editors starting new Portals

User:The Transhumanist,

you wrote:

@SmokeyJoe and Paulmcdonald: Approval, by whom? As with other departments, such a page would be facilitated by a few regulars, and so bias always sets in. One was set up, sort of, with dismal results. They denied approval to an editor who wanted to create the cannabis portal, so I advised him to create it anyways. The department also turned into a bottleneck and created a hoop-jumping exercise. Many editors decided not to create any portals because of it. I mentioned "sort of", because it was suggestive only. We can't censor Wikipedia, but we can delete material that doesn't follow Wikipedia content policies. Because of the way the department was portrayed, people were under the impression that approval was required, but it wasn't. The only requirement for creating a page on Wikipedia is clicking the "edit" or "create" tab. The same thing applies to draft space and WP:AfC: they're optional. "Wasn't approved" is not a valid argument at the deletion departments. Wikipedia has developed into the wonderful resource that it is, because people are allowed to take the initiative - it is the core defining principal of the Wiki model and what makes it work. We don't wish to dowse the creative spark. Also, you sometimes don't know if something is going to work until you try it. If a portal proves to be inviable, it can be deleted. I like the deletion system, because it has a good cross-section of involved editors. An approval department is more like a hidden cabal (closed forum). Who do you invite to the discussions? With deletions, that's obvious: the creator and major contributors. But, with a page that hasn't been created yet, you don't know who the major contributors would be. The current system works fine. If it ain't broke, don't fix it. — The Transhumanist 22:30, 3 May 2018 (UTC)

Some good important points. The WikiProject Council is not very active, I would call it haphazard. Requiring approval there might just be a net non-positive bottleneck until a random anybody says "yes". Portals would be the same.
"Approval" is probably too strong a word. It begs "approval by who", suggests there is a committee, bureaucracy, yes TT, probably hopeless.
What I generally favour in many things is that a "second pair of eyes" be involved, minimally and sufficiently, in starting up any new little bureaucratic process. This includes RfCs, WikiProjects, Portals. The "second pair of eyes" is not intended to be an explicit supporter or author, but a check of sanity, technicalities. Someone proposes something (or in practice starts something), and then a second experienced Wikipedian in good standing says "yes, go ahead". Disputes, if experienced Wikipedians in good standing disagree, can go through WP:DR, or even MfD if the thing created is completely a bad idea. This would mean that someone like you can give immediate approval to anyone else, but you can't so easily stop a pair of Wikipedians proceeding with an ill-advised bad idea.
An even softer idea would be to write into instructions something like this:
It would then be up to the watchers of these pages to choose to offer advice.

> "If it ain't broke, don't fix it"?

It is my opinion, having seen them come to MfD for years, that there are plenty of ill-advised WikiProjects and Portals, and their existence adds disrepute to the rest.

--SmokeyJoe (talk) 23:48, 3 May 2018 (UTC)

And that's why we clean them up. The main problem has been an inactive WikiProject. Keep it going strong, and you'll have the editors you need to monitor and maintain the whole system.
I like your idea of reporting new portals. There could be a section for them to be listed on the WikiProject page. That way, their development could be monitored for quality and even joined by editors who wish to make them better. Finding them is a little tricky, but can be done comparing lists using AWB's list compare feature.    — The Transhumanist   00:09, 4 May 2018 (UTC)
I suggest: A list of portals, a sortable table, columns including Portal name, Parent portal (often occurs), date started, first author, current activity level.
"Current activity level"? It would be great if this were auto-reported. What would it measure? Last manual edit? Last auto-whatever? Number of page views in the last 30 days?
--SmokeyJoe (talk) 00:19, 4 May 2018 (UTC)
We tried that. Editors would edit it once, and then that entry would never be updated again. It became horribly out-of-date. And, it was redundant with Portal:Contents/Portals. List tools make it easier to track portals. SearchSuite can list all the base pages, and then you can use AWB to compare with an earlier version to find all the new ones.    — The Transhumanist   01:29, 4 May 2018 (UTC)
That's how I think it should work. Filled in once at the start, some fields auto-updating. --SmokeyJoe (talk) 02:04, 4 May 2018 (UTC)

My memory was fuzzy on this issue, so I went looking around to refresh my recall...

Portals approval department: rejected by the community

SmokeyJoe wrote: I don’t believe that Portals or WikiProjects should be allowed to be created unilaterally, without approval. For WikiProjects, there is an approval process somewhere under Wikipedia:WikiProject Council. I think a Portal creation board should exist. Does it? —SmokeyJoe (talk) 05:34, 29 April 2018 (UTC)

It took me awhile to recall the history on this, for portals. There was an approval department at Wikipedia:Portal/Proposals, but it got rejected by the community at Wikipedia:Miscellany for deletion/Wikipedia:Portal/Proposals, at my request. Some guy created the Portal:Cannabis, while I created the Portal:Thinking, both of which were nominated for deletion; Cannabis for having been previously rejected (see Wikipedia:Miscellany for deletion/Portal:Cannabis), and Thinking for not going through the approval process at all (see Wikipedia:Miscellany for deletion/Portal:Thinking). I was appalled that a page could be deleted before it was even created, so I nominated the process itself for deletion. It was marked "historical" and "rejected by the community".    — The Transhumanist   01:29, 4 May 2018 (UTC)
"I don’t believe that Portals or WikiProjects should be allowed to be created unilaterally, without approval." Backing back a but from that. Reporting would be OK. --SmokeyJoe (talk) 02:04, 4 May 2018 (UTC)
I agree. Keeping track of what portals we have, so we can look at them, would be good.    — The Transhumanist   02:47, 4 May 2018 (UTC)
On German Wiki, unless a portal topic falls under the various categories of 'relevance' (see for a translation), the creator has to garner support first. I think they have to have 3 'overseers' (i.e. maintainers) and a majority of 10 'supporters' on the approvals page i.e. 12 'support' votes and 2 'oppose' votes gets it through the process but 12 and 3 fails. I'm not saying we should clone that, but it's a less formal approach than a 'Portal Creation Board' and more in line with other Wiki processes and we might want to think about something similar. Otherwise we'll have portals for everything and it's already a challenge to manage them all. Bermicourt (talk) 14:44, 4 May 2018 (UTC)
If we can make them automatically dynamically self-updating, it won't take many editors to maintain them.    — The Transhumanist   04:34, 6 May 2018 (UTC)
For those interested on this discussion, I also initiated a related discussion here. In my opinion we need some minimum relevance/notability criteria or approval process. A portal on a narrow topic (like an individual person, or a specific video game, or a specific movie) - where the main article itself is not yet a featured aricle - should be discouraged and the editors should be encouraged to focus on improving the core article first. Arman (Talk) 10:35, 6 May 2018 (UTC)
I think creating a set of guidelines would be good. For example, a portal should be about a broad enough topic to have at least 50 (or maybe 100) or so articles that could be included in the portal. If it doesn't have that many, it's not really worth the effort to create the portal as just visiting the main topic would likely give you enough information and/or links to relevant related articles.
I reject any notion of requiring approval to create one. That's just a layer of bureaucracy. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 20:23, 18 May 2018 (UTC)
I agree with the idea of guidelines and translated German Wiki's guidelines to see what they said. They've kept a lid on portals by requiring evidence that the portal will be maintained (which it will need if it's more than a showcase page and is being used e.g. to support WikiProjects) and strong support from around a dozen editors. So it's not an approval committee, but does reduce the likelihood of someone creating a half-finished portal on a non-notable topic area, which seems to have happened on English Wikipedia. Bermicourt (talk) 21:14, 18 May 2018 (UTC)

So what do you guys think? I see some merit to an informal approval process where more than one editor must agree that the portal should be created, but I don't think we should go as far as the rigorous approval process employed by the German Wikipedia. — AfroThundr (u · t · c) 03:28, 27 September 2018 (UTC)

  • I am open-minded about what sort of pre-approval is best. German-style bureaucracy rarely works well on en.wp, so something lightweight is best. I suggest a negative process, (like with PRODs or speedy deletion or WP:CFD/S) where approval is assumed unless contested. If the project has agreed on criteria for new portals, then it should be simple to create a DYK-style template in which the proposer assesses their own idea against the criteria, and others can chime in if they see a problem.
But something is needed to deter the sort of portal-spam we saw in the @The Transhumanist's recent drive-by spree of >400 new portals in only 12 days. That expanded the total number of portal count by ~20% and in many cases with only about 90 seconds time between them.
If this project is actually about enhancing navigation rather than creating pages for their own sake, then it needs at the very least to put an abrupt halt to such antics. --BrownHairedGirl (talk) • (contribs) 04:32, 27 September 2018 (UTC)
  • Oppose – Creation approval = bad idea. Quality control is handled via deletion. If a portal doesn't meet muster, then it is subject to deletion. To have another level of bureaucracy is plain wasteful and inefficient. But it really means that a portal you plan to create can be deleted (prevented) before you even create it. That is, before it ever has a chance to get reader feedback. So no, I'm not in favor of any approval process because it is really an additional deletion process in disguise. Let our deletion systems do what they were designed for: cull the bad after giving them a chance to be good. In essence, approval processes are a form of censorship. We don't really want portals blocked via contest. If all someone has to do is contest a portal creation request to block it, they've managed to delete the portal before it ever exists. That's almost as bad as time travel, where someone could go back in time and erase you, from history.    — The Transhumanist   08:41, 27 September 2018 (UTC)
    • @The Transhumanist: I don't believe this would become an issue in the majority of cases, especially once we have consensus on what the criteria are. Anyone who has an anti-portal stance would not be able to block legitimate portal creation in that case. As we all know Wikipedia is not censored, and any attempts to manipulate policy or other community mechanisms to cause that effect can (and would) be dealt with by the community. Also, as you've mentioned elsewhere, creation and deletion stem from the same criteria. It's the same with articles - if they don't meet the minimum criteria, they could be deleted, or moved to draft space, and if they were created as a draft, they wouldn't graduate until the concerns were met. Perhaps we should have a Portal:Draft where we can build new portals without threat of immediate deletion. Once they are fully built and ready, they can be moved to become a top-level portal. Portals under the draft portal would behave like draft articles do, namely they are "under construction" and are expected to improve before being subject to significant scrutiny. Also see my other responses below. — AfroThundr (u · t · c) 14:45, 30 September 2018 (UTC)
  • Comment – BHG appears to have a problem with portals in general (she suggested a limit above to allow level 1 portals only), and appears to be attempting to limit portals by any means she can, including before they are even created, by mere contest. The portals she has pointed out at MfD as problems look unlikely to be deleted. If there is a problem with the contents of any of the portals I have created, show us. One of two things will happen: either they will be fixed, or they will be deleted. But, the main issue that BHG has focused on is scope, which also pertains to blocking portals from being created in the first place. Don't fall for it. It's another form of deletion of portals before they even exist. It's an approval process put in place in the form of a filter. Be careful what you wish for.    — The Transhumanist   08:41, 27 September 2018 (UTC)
  • Oppose having a creation approval process is a bad idea. The main reason I think it is a bad idea is by looking back at history. This WikiProject went inactive and so did the featured portal process. This is one of the reasons why portals, in general, became outdated. Having a process to create portals allows the possibility for the process to become inactive and so no new portals would be created and would also lead to the portal namespace becoming more outdated as new topics are not accounted for by their own portal. Dreamy Jazz 🎷 talk to me | my contributions 11:35, 27 September 2018 (UTC)
    • @The Transhumanist: The deletion process serves as the counterpoint to the creation, yes, but if for instance, 10% of the recent portals created end up at MfD with 5% actually getting deleted, that may be a sign that we could improve on that. Also Dreamy Jazz, I'm pretty sure nobody here wants the full "approval department" scenario. I'm more suggesting the informal method of announcing the portal beforehand. BrownHairedGirl's negative process is a decent one. Instead of waiting for X more editors to agree on the creation, if there is no objection after a day, it gets created. If someone objects, we go through the whole discussion. I see the latter case being a minimal occurrence. I would also add that the process, being informal, would not be required, but suggested, like AfC is. If you're sure your portal is the bees knees and everyone will love it, they can go right ahead with creation. This is intended to provide an optional venue through which others who aren't as certain (or are certain, but have a problematic creation track record) can get a second opinion. — AfroThundr (u · t · c) 01:27, 28 September 2018 (UTC)
  • Oppose - A portal is akin to an article in this regard to me; any autoconfirmed editor should have the ability to create one. — Godsy (TALKCONT) 05:40, 28 September 2018 (UTC)
    • @Godsy: AFAICT, this would not prevent editors from creating portals directly, as it would not be mandatory. Perhaps I should've explained that better. Nothing technically prevents editors from creating a portal directly, just like nothing prevents them from bypassing AfC entirely. This would be for cases where the success of the portal-to-be is not certain. — AfroThundr (u · t · c) 14:25, 30 September 2018 (UTC)
      • @AfroThundr3007730 and Godsy: I think we differ here. I don't see much point in an optional pre-creation process, because the most prolific portal-creator is also the most averse to restrictions in scope or to pre-approvals. So an optional process would have negligible effect on the flow. It would be like placing a roadblock on a back road while the parallel 10-lane highway was unmonitored. --BrownHairedGirl (talk) • (contribs) 14:51, 30 September 2018 (UTC)
        • And if the outcome of the RfC restricts portals to, say, +500 articles (disqualifying many of the recently created portals), everyone would have to respect the new consensus. I don't believe anyone here would blatantly disregard the community decision once it has been clearly defined. There are processes for that scenario already in place, should it occur. I'll keep using AfC as an example, but if an editor has a track-record of failed articles, they could be required to use the curated creation and submission process developed by the community, via sanctions. This also goes the other way, should the community decide that small-scale portals are fine. — AfroThundr (u · t · c) 15:08, 30 September 2018 (UTC)
          • I wish I could share your optimism. But given what I have seen already of TTH's prolonged outrage that anyone might not share their view, I think much drama would be avoided simply by making the pre-scrutiny phase universal. It would save the drama of multiple MFDs. And I really don't see any point in a pre-approval process if the most prolific operator can simply ignore it. --BrownHairedGirl (talk) • (contribs) 15:28, 30 September 2018 (UTC)
            • This only really an issue because the guidelines do not reflect the current state of affairs (and won't until the RfC is done). Everyone has a different interpretation of them in their current state, in conjunction with the (inconclusive) previous RfC closure. As I've mentioned before, I don't believe anyone here would ignore the guidelines, once they have been clearly defined by community consensus. If new portals created after the RfC and revised guidelines continue to fall short of the minimum criteria, they would be MfD'd like usual, and for editors with continuously problematic submissions, there's WP:RESTRICTIONS for that. As I've said, there are already processes in place for this. — AfroThundr (u · t · c) 15:41, 30 September 2018 (UTC)
  • Oppose – More unnecessary bureaucracy and red tape. The deletion process can be used to address portals that are significantly deficient. North America1000 22:51, 5 October 2018 (UTC)

We should attempt to find a consensus on the above in order to draft modernized portal guidelines, along with an RfC that will survive WP:VP scrutiny. Perhaps now that the discussion has cooled for a month, we can now revisit this and make some decent progress toward that goal. — AfroThundr (u · t · c) 17:19, 5 November 2018 (UTC)

Discussion (continued)

@The Transhumanist, Evad37, Certes, Dreamy Jazz, Pbsouthwood, SMcCandlish, FR30799386, BrownHairedGirl, Godsy, Finnusertop, Cactus.man, BrendonTheWizard, Bermicourt, Paulmcdonald, and Northamerica1000: I know you guys are probably tired of this by now, but if we don't find a solid consensus, this will just rear it's ugly head again later. — AfroThundr (u · t · c) 17:33, 5 November 2018 (UTC)

The appropriate venue for discussions about the portal guidelines is Wikipedia talk:Portal guidelines. And, to avoid the chaos that occurred in the above discussion in order to keep things simple, issues should be addressed there one-at-a-time, one per thread. See you there.    — The Transhumanist   18:14, 5 November 2018 (UTC)
I am quite happy to consider and discuss polite, positive suggestions that are on topic. I agree with AfroThundr that this should be settled if possible. Does anyone have a reasonable proposal to start from? Maybe someone who does not represent either extreme of the dispute? · · · Peter (Southwood) (talk): 07:22, 6 November 2018 (UTC)
@Pbsouthwood and AfroThundr3007730: I think the scope (notability) threshold in place currently is fine (see Wikipedia:Portal guidelines#Article selection), and that there is no compelling reason to seek a new consensus to change it. However, the guideline itself is woefully out of date and needs to be updated. See the thread below to make a start on that.    — The Transhumanist   05:04, 7 November 2018 (UTC)
I think there are some points that should be clarified, such as which items the number of 20 refers to. Is it each or a sum, and if a sum, which parts apply. · · · Peter (Southwood) (talk): 06:35, 7 November 2018 (UTC)
"About 20". As written, it applies to each such section, but, as most portals have a single selected articles section, this figure essentially equates to the minimum number of articles a portal is recommended to be populated with (its a guideline). Keep in mind that this number has not been observed as a minimum in practice, as a great number of portals utilizing subpages present far fewer than 20 articles. The defacto minimum has been "1". Click on https://wiki.riteme.site/wiki/Special:AllPages?from=1&to=&namespace=100 to inspect how many selected article subpages the various portals have. You will find that a large proportion of the original portals have just a handful or less.    — The Transhumanist   10:33, 7 November 2018 (UTC)
This discussion is continued in the #Concerning section: Article selection thread, below. Please post new comments there.    — The Transhumanist   10:42, 7 November 2018 (UTC)
As a side note, I may not chime in on all of the below discussions, but I am still watching them develop. — AfroThundr (u · t · c) 17:31, 7 November 2018 (UTC)

Pause on mass creation

I opened a discussion at the Village pump, Wikipedia:Village_pump_(proposals)#Hiatus_on_mass_creation_of_Portals. UnitedStatesian (talk) 14:35, 26 February 2019 (UTC)

Portal icon request

Hello all, I've done this once before but couldn't recall if this was the place to ask—but I'm posting it here anyway. I was wondering if someone could assign an icon to a portal for me. The portal is Portal:Courtney Love, and I'd like to assign this icon if possible. I believe someone qualified has to do this, or if there is a way for any editor to do so, let me know. Thank you! --Drown Soda (talk) 02:22, 14 February 2019 (UTC)

The icon names are stored in protected templates. Please see Template:Portal#Image. Certes (talk) 02:43, 14 February 2019 (UTC)
 Done ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 23:13, 26 February 2019 (UTC)

Portal creation and deletion criteria proposal 4

I am going to suggest a variant of @Dreamy Jazz:'s.

Every portal must have at least 20 selected articles. Articles that have already been selected by another portal are not counted towards the 20 for the latter portal(though obviously they can still be included).

My reasoning for this amended proposal is partially similar to that of proposal 1:

  • "It is generally accepted that a portal won't survive MfD if it does not have 20 selected articles
  • There has been significant concern from other editors about how some portals are pretty much duplicating another parent or related portals content, without adding much. This would ensure that this is catered to. This will also help the portal namespace, in that readers are not split into different portals when the portal contains very similar or the same information."

With the key added reasoning:

  • It doesn't make any sense for an article not to add value at all, just because two portals have claimed it. Splitting in this way means that articles which obviously apply to more than 1 portal can exist in them and supporting some portal existence, while still requiring a unique remit for a new portals, to avoid needless duplication.

As obviously a partially amended version, if proposal 1 decides to change this can obviously be merged/scrapped. However I feel it is a substantial difference and warrants a separate consideration until that point.


A couple of questions that affect the practicability of this proposal:
  1. How does one check whether an article is already used in another portal?
  2. Which portal gets to claim an article? Sometimes the portal where the article is most relevant will not be the first portal created. This will happen when a portal is split into subportals because it is too large, but in that case it is unlikely that there will be a dispute, but many articles are shared by very different projects, as can be seen by the presence of multiple navboxes. I think this rule will lead to much unneccessary drama, but you may have a solution which is not currently obvious to me.
  3. Where is the harm in duplication? It requires no additional content, and no additional maintenance. All it takes it presence in the navbox. If it adds no value in the navbox, remove it from there and it will softly and silently vanish away. The new model portals are Boojums you see.
  4. A potentially useful portal may be possible where every one of the articles is shared with another portal, but no two articles with the same portal. Would this still be considered a problem? · · · Peter Southwood (talk): 14:45, 28 February 2019 (UTC)
  • Support (as proposer) - it seems to have the benefits of proposal 1 while avoiding a key problem. Nosebagbear (talk) 11:56, 28 February 2019 (UTC)
  • Tentative support in principle depending on whether the questions above can be satisfactorily answered. I agree that excessive overlap is undesirable, but it may be difficult to test, and there may be overlap with multiple portals. I would say excessive overlap means a large proportion of articles are shared by any two portals. I don't know where I would draw the line though. 50%? · · · Peter Southwood (talk): 14:45, 28 February 2019 (UTC)
    • Per your point #4, I would say any two portals that have over X% overlapping articles (50% sounds okay) would count, but not the portal with a single article overlapping with dozens of others. And if we're limiting the criteria to the two-article case, comparing them for overlap becomes trivial. Nobody is likely going to pony up the cycles to do an "overlap percentage analysis" on the portal network for the higher-number cases. This distinction could be better captured in the proposal though. Tweak the second sentence to something like A portal should not contain a significant proportion of articles that overlap with another portal. maybe? The concern, I think, should be less about the number of "unique" articles per portal and more about how "unique" two particular portals are when compared. — AfroThundr (u · t · c) 02:59, 1 March 2019 (UTC)
      • Sometimes it is obvious that a portal already exists that uses an article, because there is a link to the portal from the article, but when one is considering creating a portal, what checks do you have in mind to avoid the problem of excessive overlap? · · · Peter Southwood (talk): 06:04, 1 March 2019 (UTC)
        • @Pbsouthwood: Due diligence might include a namespace search for existing portals covering a similar topic, or close to the proposed portal in the (as yet to be created) navigation tree. Then using What Links Here might be helpful, although the nature of the selected excerpt templates would mean the results wouldn't exactly be complete. Also, comparing the wikisource would miss links in the navigation boxes... hmm...
          I wonder if we could build an "index" of portals and the articles they link to (rendered as a wikitable, or even just JSON or something). It'd take a bot crawling the namespace regularly (and expanding all templates) to generate such an index, which could then be hosted on-wiki and made searchable. A userscript could accompany said index to make the "uniqueness" checking easier. This is a case that I don't expect to be enforcing immediately after implementation, since we've got bigger fish to fry, so we'd have time to build that.
          @Dreamy Jazz, Evad37, Certes, and The Transhumanist: Thoughts on this idea? I figure a technical solution wouldn't be out of place here, considering the scale. — AfroThundr (u · t · c) 06:48, 3 March 2019 (UTC)
          • A Quarry query on pagelinks could detect when a portal overlaps others. It only works on existing portals and may be too expensive to run on all portals at once. Therefore it would only be a tool to evaluate an existing portal that looks suspicious, rather than a pre-creation check for a prospective new portal or a way of finding candidates to delete or merge. An offline tool (read-only bot) could select all links from portals and generate statistics such as listing portals which share almost all outgoing links with other portals and naming those overlapping portals. I don't think this can be done efficiently on Quarry, as we can't create temporary tables. The results may vary depending on which articles are being randomly selected for display today. There's also no notion of articles being "already selected by another portal". Portal:Australia and Portal:Mammals both link to Kangaroo, and the query won't resolve the resulting bunfight over which portal gets to count that article towards its quota. Certes (talk) 11:59, 3 March 2019 (UTC)
I've produced a couple of Quarry queries which aren't exactly what we want but may be useful.
  1. Portals linking fewer than 20 "new" articles, where "new" here means "not also linked to a portal which was created earlier"
  2. Portals which also link to a portal's articles, which needs to be amended with the title of a specific portal before use
Hope that helps. Certes (talk) 16:04, 3 March 2019 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia_talk:Portal/Guidelines/Archive_8&oldid=1238026808"