Wikipedia talk:WikiProject Portals

From Wikipedia, the free encyclopedia
  (Redirected from Wikipedia talk:WPPORT)
Jump to navigation Jump to search
WikiProject Portals Talk Pages

Tasks and

New Post | Watch Page
To discuss work on the portals, and project administration, including policy issues.

Dialog-information on.svg
Portal Design
and Ideas

New Post | Watch Page
Existing and potential portal design features and support tools. Technical stuff.


New Post | Watch Page
General portal topics and announcements that don't fit elsewhere

Shortcut: WT:WPPORT/A

Shortcut: WT:WPPORT/D

Shortcut: WT:WPPORT


Main Discussion Page

Shortcut: WT:WPPORT

All Discussion Sections

Archives: Index1, 2, 3, 4, 5, 6
WikiProject Portals (Rated Project-class)
WikiProject icon This page is within the scope of WikiProject Portals, a collaborative effort to improve portals on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 Project  This page does not require a rating on the project's quality scale.
Note icon
See also: Instructions • Guidelines • List of Portals

General discussion threads

Proposed new quality class assessments

I think that we should be looking at introducing more quality levels to assess portals – there's quite a gap between underdeveloped portals and fully developed, good-quality portals. Notwithstanding that there may be further technical developments, I propose the following class system for portals:


Portal B-Class criteria
Portals may be assessed as B-Class when they are complete and without major issues. Specifically, the portal is:

  • Useful. Provides:
    • an introduction to the topic or topics the portal covers, long enough to be useful but short enough as to not be distracting
    • a variety of sample content sections (typically one or more sections for articles, one or more sections for images or other files, did you know? items, and in the news items)
    • navigation to help users find their way to the most relevant Wikipedia material within a particular subject
    • a bridge between reading and editing, by providing links to relevant areas in the Wikipedia community associated with the portal's subject
  • Broad in coverage. Each selected content section has at least 20 items on random rotation, or is manually updated on at least a monthly basis (either manually or via automated means).
  • Up to date. Significant changes to article content are reflected in the portal content, either via transclusion or manual editing.
  • Formatted appropriately. While an attractive and aesthetically pleasing design is desirable (and part of the featured portal criteria), all that is required for B-Class portals is that:

B-Class here is comparable to B-Class for articles, in that its for stuff that basically complete with no issues, and does not require much MOS compliance. There is also room for a GPo (Good Portal) class, which could have stricter requirements than B-Class (a new process might be easier to set up, rather than reviving the Featured Portal process). What do you all think? - Evad37 [talk] 05:10, 15 June 2018 (UTC)

@Evad37: Looks good to me. The only change I'd suggest is in the Broad in coverage criterion: manually updated on at least a monthly basis. Does it have to be manual? There are ways of automating portals so that they show specific content at specific times; it would be hard to argue that a portal that automatically cycles through 52 articles, showing a different one for each week of the year, is not broad in coverage. WaggersTALK 11:49, 15 June 2018 (UTC)
I'm also liking this, and the GPo class sounds like a good idea as well, once we get the guidelines ironed out. I also agree with Waggers on the point that a portal doesn't necessarily need to be touched monthly to be relevant and up-to-date. That was one of the reasons of implementing heavy automation - the transcluded articles carry most of the maintenance weight. Work smarter not harder, and all that. @The Transhumanist: we should probably mention this in the next newsletter for wider visibility. — AfroThundr (u · t · c) 12:53, 15 June 2018 (UTC)
@Waggers and AfroThundr3007730: Agreed, and changed it above. The intent was just to note automation isn't an absolute requirement, i.e. manually maintained portals can still be B-class if they otherwise meet the criteria. - Evad37 [talk] 14:30, 15 June 2018 (UTC)
  • If we use any schema that has anything like a "formatted appropriately" checklist item, I think we should recommend compliance with the draft WP:Manual of Style/Portals. While it is not presently a {{Guideline}}, it likely will become one (and less controversially than some other MoS pages, because no one's working on it who isn't also in an "I care about the portals" frame of mind (i.e., there's not an "opposition camp"), and the goal of it is to explain how to apply the key parts of MoS to portals (and point out where some article-specific line items don't really logically apply to portals), not to invent new restrictive "rules" out of nowhere, nor to diverge sharply from MoS's central concerns.  — SMcCandlish ¢ 😼  10:46, 17 June 2018 (UTC)

Portal assessments: exploring other schemata

Since portals are not articles, maybe we should go completely customized. Otherwise, A, B, C, etc. could be applied out of context, or be confusing. Maybe something like this, instead:


As we are going for automation, quality should be built-in to the automation process. Featured status would become superfluous when the criteria are all met automatically by the software. Featured status would lose its meaning, and might acquire other connotations such as "not featured because editors have not gotten around to discussing it yet, or even to applying." I plan on making some awesome portals, but I won't be submitting any nominations -- I'd rather use the time to build new portals. If we upgrade all 1500 portals to a high-level of automated quality, how long would it take editors to assess them all to featured status? Assuming one approval every two days, it will take over 8 years. And that's without considering future portals that do not even exist yet. 3000 portals would take 16 years. Excellent portals will be sitting there waiting forever to get certified.

I'm also concerned that with the lack of editor labor, a featured portal department would distract editors from higher priority portal-related activities such as designing innovative new components that would ensure quality, and performing AWB runs to install those new components.

Another concern is that if a featured portal department has only an editor or two, or just the nominators, what purpose would it serve? I'm concerned that it will turn into another portal approval fiasco driven by personal bias. They rejected a proposal to create the Cannabis portal, for example. Though the bottle-necking problem is my main concern.

It might be nice to have some other top-rating, which all portals can attain without bottle-necking. Perhaps foregoing an approval process in favor of an assessment process would work for portals. Thoughts?    — The Transhumanist   20:03, 15 June 2018 (UTC)

Some very good points here. It would definitely be good to remove subjectivity as much as possible. With truly objective assessment criteria it could be possible to self-assess, or perhaps even to build a tool that automatically checks a portal against a series of criteria and produces appropriate feedback. But even that arguably takes us away from the task of building more, better, portals.
The good/featured article processes have become a heavily backlogged, overly picky/bureaucratic nightmare and it would definitely be wise to put measures in place now to avoid the same happening with portals. WaggersTALK 20:26, 15 June 2018 (UTC)
@Transhumanist and Waggers may I suggest this is not an either/or selection. WikiProject templates can have subfields (see e.g. the "discipline" field here: {{WikiProject Anatomy}}). I think an open display and recording the automation as a subfield is extremely useful to know for readers and editors alike, but that it shouldn't take the place of a quality assessment... so a subfield may be the way to go here. --Tom (LT) (talk) 09:25, 17 June 2018 (UTC)

Portal assessments: Another alternate approach

The Transhumanist I'll just point out that most of the classes in your example seem better suited as maintenance statuses and metadata, not necessarily a reflection of the portal's quality, which would be closely tied to its source articles in a heavily automated scenario anyway. You have a point though about A/B/C ratings, and I agree with Waggers on the FA/GA problem, which leaves us with no assessment classes. This may be a good thing, though. Portals are kind of meta to the topic they cover, and should just be a gateway to explore said topic. From a purely mechanical perspective, they should all have the same "quality". We could instead just focus on ensuring they work as intended, are as complete and comprehensive as possible, and have no issues that would interfere with the reader's exploration of a topic.
Or if we do want some way to differentiate portals that meet the minimum criteria from those that go above and beyond, perhaps a simplified binary state - Good portals (separate class) and Normal portals (no special class) - would suffice for our purposes? I hesitate to use the term "Good Portal" because of the GA problems already mentioned, but maybe that process can be simplified here. Portals nominated for GPo would just need to be reviewed and approved by a group consisting of members from this WikiProject, and possibly the primary WikiProject covering the portal's subject area. We would define our own "good" criteria that wouldn't have to be as strict as WP:GACR, since that's not applicable to portals anyways. The FPo class would remain historical in this case.
If we wish to avoid GPo altogether, we could swap "Good" and "Normal" above with "B" and "C" class, and don't go any higher. Maybe add stub class too, which covers incomplete portals, and draft would cover under-construction pages. The portal's automation status is kind of orthogonal to quality, I think, as long as editors are willing to put in the work. This kind of merges the two proposals above. Ping Evad37 too, what do you guys think? — AfroThundr (u · t · c) 22:03, 15 June 2018 (UTC)
Instead of "Quality assessment", we could call it "Completion assessment", which is, after all one of the main qualities we are looking for in portals. Even if they are just utility status ratings, having them displayed in the WikiProject banner box would be nice. Thoughts?    — The Transhumanist   22:26, 15 June 2018 (UTC)

Quality is different to automation or maintenance status, which already shows up separately in the project banner (if the portal is marked with {{Portal maintenance status}}). For example, a fully automated portal that has a one sentence introduction, two article excerpts on random rotation, and three pictures on random rotation would still be a low quality portal that's lacking content; while a fully manual portal with dozens of subpages, with someone keeping the whole thing up to date on a monthly basis, would be a higher quality portal. Completeness also is not quality, just one aspect of it. A portal may be complete, as in it has all the sections it's meant to have, but again if it doesn't have much content to go in those sections, then its not really a quality portal.
Regardless of what we call the classes, I think the criteria I wrote above – useful (i.e complete), broad in coverage, up to date, formatted appropriately – are what we should be trying to achieve. How one goes about it is a different matter, but thus far we've been reassuring everyone who asked that the new automation and selective transclusion techniques are not required, and "there's more than one way to produce a good portal".
GPo was just a thought bubble, we can leave it and other higher-quality class proposals to the side, and mark the featured FPo class as historical in the table. (Perhaps it or something similar can be revisited later on, if we can come up with a light-weight process.) – Evad37 [talk] 01:15, 16 June 2018 (UTC)

  • some already made experiences ... we have made in de:WP with a centralized system for assessment. See Translation. This worked well as long there was somebody who maintained this. Since 2013 our assessment is out of order. If you think about any points which could be good enough to keep ... I propose to keep a notice about the colleagues who mainly support special portals. It is good in order to find a contact person and for the motivation to keep them up to date. Best --Tom (talk) 12:09, 16 June 2018 (UTC)
  • I lean toward AfroThundr3007730's view on this. A schema of Stub → Start → C → B → A/F is better suited for articles, and is apt to be confused with with them. I think we should be more concerned with completeness/richness of feature set, and how well the material is presented and selected. Because portals are very meta, that's really what portal quality boils down to. E.g., it would be possible to create a stellar quality portal for cue sports, given enough hands on deck, despite the dearth of GAs and near absence of FAs in that entire category tree (most of the GAs and FAs we do have on pool, snooker, and billiards are about historical figures in the sport from the late 19th century to around the 1980s, and would not be central content in a cue sports portal anyway, which would almost necessarily focus on current champions and championships, like any sports portal, with historical matter being a section or a sidebar, and more apt in that part to focus on the evolution of the games than on particular bios. Anyway, the point being: GA/FA levels in the category don't really have much of a connection to portal "quality". It's more a matter of how well they serve as entry points into their respective topic areas and, probably, how frequently they are maintained. I think the maintenance thing is always going to be the real issue. We have a tremendous number of portals that are basically unmaintained, so the more we can automate it, the better. And doing that is primarily a matter of standardization, which is one of the reasons I think the draft MOS:PORTALS will be important (though right now it's very skeletal and spotty; we probably need to identify, MOS:LAYOUT-style, exactly what a portal should contain, perhaps by portal type – events ones, including sports, politics, etc., are different in nature and intent from, say, ones on classical antiquity or art history. PS: The assessments in the table laid out under "Portal assessments: exploring other schemata" are probably a good start, but may just be major categorizations under which we'd need to be more specific. How current is it? How well illustrated? Is it drawing from the entire category tree of the subject? Is it over-focused on the US and/or UK (in a topic area not dominated by either country like baseball and cricket, respectively)? And so on. Some of the label descriptions in the original assessment table under "Proposed new quality class assessments" above actually make a lot of sense; it's the "B", "Start", etc., labels that are questionable.  — SMcCandlish ¢ 😼  11:01, 17 June 2018 (UTC)

Refined proposal

Here's a refined version of the first proposal, taking into account the comments from above. A completely new set of class labels is used so there's no confusion with article classes, and I removed the row for Featured Portals (they can still be marked with that historical featured status elsewhere, but for our project banner they would be assessed according to the same standards as other portals). The criteria are now numbered and have a better introduction; added new criteria 2(b); criteria 4 is now based on the MOS (draft) guidelines; and there's some other more minor changes.

Portal quality criteria

Portals are assessed based on how well they serve their purpose as entry points into their respective topic areas. High quality portals are:

  1. Useful. Provides:
    • (a) an introduction to the topic or topics the portal covers, long enough to be useful but short enough as to not be distracting which follows the Wikipedia:Manual of Style/Lead section § Introductory text guidelines
    • (b) a variety of sample content sections and navigational sections, as well as a bridge between reading and editing, per Wikipedia:Portal guidelines § What content to include (typically one or more sections for articles, one or more sections for images or other files, did you know? items, and in the news items)
    • (c) navigation to help users find their way to the most relevant Wikipedia material within a particular subject
    • (d) a bridge between reading and editing, by providing links to relevant areas in the Wikipedia community associated with the portal's subject
  2. Broad in coverage.
    • (a) Each selected content section either has at least 20 items on random rotation, or is automatically updated on at least a monthly basis.
    • (b) Content is representative of the entire topic or topics the portal covers, and not overly focused on specific aspects. Portals should present a worldwide view of the topic, unless the topic specifically relates to one or more countries or geographical areas.
  3. Up to date. Significant changes to article content are reflected in the portal content, either via transclusion or other automated means or manual editing.
  4. Formatted appropriately. Follows the (draft) guidelines at Wikipedia:Manual of Style/Portals.

- Evad37 [talk] 14:41, 17 June 2018 (UTC) Updated 07:13, 20 June 2018 (UTC), see section below

This looks good, although there has to be a better name than "broken", I think. I also agree on not including FPo as an official class, since it's historical. It can be recorded with a separate note in the project banner, like historical is. To that end I made these changes. I'm pretty sure I did it right, although there's probably room for improvement (more on that on the module's talk page). — AfroThundr (u · t · c) 03:03, 18 June 2018 (UTC)
I like the concept that completeness and usefulness are top priorities. An excellent portal in terms of functionality and usefulness to the reader should not be unduly handicapped by a huge topic of low quality articles. That is a separate issue, though also important. Similarly a small set of really good articles in a topic can be badly served by an incomplete, out of date or illogical portal structure. This type of criteria will encourage portal builders to concentrate on the functionality, and less on tweaking for prettiness. Better functionality may mollify the more rational opponents of portals. · · · Peter (Southwood) (talk): 09:16, 18 June 2018 (UTC)
Broken may be the simple truth. If broken, it should be open for repair by anyone who cares enough, failing that, it should be available for merging into a wider scope portal (preferred), either as components or as a sub-portal, or for deletion (if it should not really exist). I am rather in favour of fewer but more extensive portals, but also think that we should concentrate on the development of a few R&D portals to work out what is possible, develop the tools and then apply the new standards. To futher this end I suggest each member who is interested in the R&D side select one or two portals and play around with them to experiment with the possibilities that exist and to come up with ideas for tools that don't yet exist. A standard format for portals that are not maintained by specified users would be useful, so when a portal is tagged for deletion or as broken, or appears to be abandoned, anyone can make a relatively quick fix. · · · Peter (Southwood) (talk): 09:31, 18 June 2018 (UTC)
I think we should include the criteria at Wikipedia:Portal guidelines in assessments. They're backed by longstanding consensus, unlike MOS:PORTALS which may or may not pass. The proposal also contains some very vague wording. How does one even fail "navigation to help users find their way to the most relevant Wikipedia material within a particular subject" if the portal meets the more specific requirement at Wikipedia:Portal guidelines to transclude a category tree?
On a more fundamental level, if we know that regular maintenance of portals has historically been neglected, that's even more true about talkpage assessments. I expect these to be quickly outdated. 2a has the potential to be outdated every month. A minute change could turn a Substantial portal to a Complete one or vice-versa. The community is already moving toward automation in article assessment, so we're fighting the current here. – Finnusertop (talkcontribs) 10:05, 18 June 2018 (UTC)
I agree in principle, with the proviso that Wikipedia:Portal guidelines may need some updating, and that changes will take time to implement.
Are you suggesting that portal assessment can also be automated? I like the idea. It is another thing that would not have to be taking up editing time. I think this could wait and see how automated article assessment goes, and jump on that bandwagon if it gets up to speed. Or start earlier if that is your suggestion and you have ideas on how to do it that are implementable. · · · Peter (Southwood) (talk): 10:20, 18 June 2018 (UTC)
Just saying that the scheme proposed here unlikely lasts forever, which means potentially a lot of wasted work. And when the time comes, we should design criteria that are easy to gauge automatically. – Finnusertop (talkcontribs) 10:51, 18 June 2018 (UTC)
Very true. Not worth over-investing until most of the bugs are ironed out. We should do a few samples and see how it goes. I will nominate Portal:Underwater diving for the value of the feedback, because I am willing to tinker with it, and because it is a bit different. I think that actually using the criteria is a good way of checking how user-friendly they are. Cheers, · · · Peter (Southwood) (talk): 11:02, 20 June 2018 (UTC)

Discussion of specific items in the quality criteria:


  • 1(a). If a lead is transcluded for the intro section, the lead should comply with MOS:LEAD in all respects. This can be relaxed for automatically selected articles in other sections, as it would be unreasonable to expect the template to discriminate with any accuracy, and the lead quality may vary enormously within a topic. Usefulness is served better by including lower quality leads than excluding them altogether, which goes against completeness. If the root article does not comply, fix it. Both the article and the template are thereby improved.
  • 1(b). Some topics are unsuited to DYK and/or In the news. Having a box that never displays anything is not useful. In some cases there may not be a useful set of images available. A crappy slideshow is worse than no slideshow.
  • 1(c). Absolutely. Navigation is useful. Provide it in as many ways as seem appropriate for the topic. I am experimenting with this.
  • 1(d). Great if we can get it to work. Worth as many tries as people are prepared to make. We don't know if anything will work until we try it. I would like to elicit feedback from readers, but not like the previous WMF disasters. Feedback that is actually useful to the people writing the articles in the portal's topic. Are readers finding what they are looking for, is the content understandable, what is missing., are there factual errors.? That sort of thing.
  • 2(a). I think this may be too prescriptive, but don't have a solution yet.
  • 2(b). This is a difference between a a complete and an incomplete portal.
  • 3. How do we measure this?
  • 4. Yes. Assuming an appropriate MoS:Portals.

Do we put any upper limit to the size or complexity of a portal? If it crashes the server? Exceeds the transclusion limit? Takes too long to download? Cheers, · · · Peter (Southwood) (talk): 10:10, 18 June 2018 (UTC)

With all the transclusion templates and other things going on in the automated portals, I imagine they're probably heavier than the old form static portals. Perhaps we should gather some numbers to see how much additional load we're adding by comparing traditional portals with our decked-out new portals. I don't think we're coming anywhere close to WP:TLIMIT on these, but it would make sense to include this in the portal guidelines as well, not necessarily in the quality criteria. — AfroThundr (u · t · c) 12:03, 18 June 2018 (UTC)

Updated criteria

Updated again, based on further feedback (see deletions and insertions)

  • Lead guidelines already exist at MOS:LEAD, so let's just follow that (the introductory text section specifically).
  • The portal guidelines already specify what content should be included, so again we can just defer to them. Thus 2(b), (c) and (d) are combined into one point
  • Now requires automatic updating via transclusion. Portals not using transclusion would fail #3, as they could become outdated at any time. Monthly updates is still an option for 2(a), e.g. for selected anniversary sections using {{transclude selected excerpt}}. This effectively means that manually maintained portals could not be rated higher than "Substantial".
  • The automation requirement also means that "Complete" assessments would be unlikely to become outdated. The other assessments will proved lists of portals to work on, so an outdated assessment there would be resolved by working on the portal and then updating the assessment, or just updating the assessment, as the list is worked on.
  • While mw:ORES or other automated assessment methods may be available for portals in the future, there's nothing that can be used currently (and I'm not aware of anything being worked on). Manual assessments at least provide an idea of how we're going, and what should be worked on. Anyone who thinks assessments are (or will be) wasted effort is not required to do anything with them.
  • As long as we're not actually exceeding the template/lua limits, I don't think we need to be too concerned about the complexity of a portal, nor any server-side issues – see Wikipedia:Don't worry about performance. The design and optimisation of templates/modules should be something we care about, but I don't think its necessary to have it in the quality criteria. As for size, I don't think any portals that would fail WP:TOOBIG; portals have much less content than fully developed articles. - Evad37 [talk] 07:13, 20 June 2018 (UTC)
OK, I will go with your probably better understanding of the inner workings. At one stage I did hit the template limit, but changed to the {{transclude random excerpt}} model and that went away. · · · Peter (Southwood) (talk): 11:07, 20 June 2018 (UTC)

Proposed criteria version 4

Originally done by Pbsouthwood as an edit to my previous post. Undone per WP:TPO and reposed here. Also removed <ins> and <del>...</del> tags. - Evad37 [talk] 07:18, 30 June 2018 (UTC)

Portal quality criteria

Portals are assessed based on how well they serve their purpose as entry points into their respective topic areas. High quality portals are:

  1. Useful. Provides:
  2. Broad in coverage.
    • (a) Each selected content section either has at least 20 items on random rotation, or is automatically updated on at least a monthly basis.
    • (b) Content is representative of the entire topic or topics the portal covers, and not overly focused on specific aspects. Portals should present a worldwide view of the topic, unless the topic specifically relates to one or more countries or geographical areas.
  3. Up to date. Changes to article content are reflected in the portal content, via transclusion or other automated means.
  4. Formatted appropriately. Follows the (draft) guidelines at Wikipedia:Manual of Style/Portals.

Lets consider a method for assessment of portal quality:

  • 1a: I think we can consider a full lead section transcluded from an FA or GA or A-class article is by default good enough for the intro section. B-class articles may or may not be OK as they stand, and should be checked against the MOS using some form of checklist.
  • 1b: If the portal is automated, do we put conditions on the class for articles which are used for selected excerpt transclusion? I think that FA, A and GA are clearly acceptable, These can probably be bot selected with an existing bot. B-class should be acceptable, as there are criteria for the lead section. These are not currently available through a bot run as far as I know. C and lower are debatable. My suggestion is that any article in which the lead meets B-class or better can be used as an excerpt source in a portal which can be rated as Complete. The difficulty here is that there is currently no easy way of automatically identifying such articles. This is a moderate challenge. We can fall back on manually categorising articles with a good lead section, but there may be a better way.
  • 2a: may be amenable to simple manual or automated counting, but 20 may be too high a bar. Some topics may have important groups of articles which may never reach 20, but are still a useful group for random selection. As an example, there may only be 8 phyla in Fungi, or 5 modes in underwater diving. I suggest that the requirement should be that if the range of available articles is limited and thought to be complete, and the leads are all of a sufficient standard, that is good enough.
  • 2b: I can see no obvious way to automate this. I think it is a matter for human judgement. I suggest that this be handled on a proposal and review system. The proposer logs the portal in a form of RfC on the talk page with a notice at all of the related projects. If consensus is that coverage is representative, then it is considered to be so until shown to be otherwise.
  • 3:Up-to-dateness of a portal can be challenged at any time by providing evidence that it is out of date. Talk page discussion, usual procedures.
  • 4: How long do we allow a portal's maintainers to catch up with new requirements of the Portal MoS? In most cases this will only make much difference to Complete portals. A small or moderate change to a MoS might drop a portal out of the complete rating to substantial, but is unlikely to substantially affect lower ratings. I think that immediate regrading with specified reason would be OK and would encourage quick fixing.· · · Peter (Southwood) (talk): 16:04, 26 June 2018 (UTC)


I agree with pretty much all of this. The class detection of the transcluded article could be done via Lua by detecting the grade in the WikiProject banners on the talk page, but that might be expensive. We should probably also pick a few other portals to pilot this on too, and see how it goes. — AfroThundr (u · t · c) 16:25, 26 June 2018 (UTC)
I have tried this out at Portal_talk:Underwater_diving#Experimental_quality_assessment, and it seems practicable. It may be more tricky to establish quality of portals that are a long way from complete using these criteria. Also I am probably biased about Portal:Underwater diving, so would appreciate an outsider's opinions. · · · Peter (Southwood) (talk): 17:10, 29 June 2018 (UTC)
While adding Wikimedia templates to the portals listed for manual fixing, I noticed a big variation in quality, and I think we should start tagging sooner rather than later. I think the quality classes listed above are a good start, and would like to start adding tags soon, so if anyone wants to suggest variations on this theme, please do so. At present, there will probably be mostly underdeveloped, a few substantial, and quite a number of broken. There may be a few complete, but that status will be insecure while we are still developing the procedures, tools and criteria. They will be important for testing, so it is fairly urgent to get a reasonable sample together. Cheers, · · · Peter (Southwood) (talk): 17:10, 29 June 2018 (UTC)
  • Assessment procedure: At this stage it is all very experimental, so I suggest we just go ahead and do a few trials and provide the assessed classes with as much talk page explanation as seems a good idea at the time. Some cases may be simply obvious, others less so. Then list the portal here for a 2nd opinion. If the 2nd opinion agrees, then we consider the assessment as OK until challenged and tag it with the assessed quality category. After a bit of trial and error we should be able to get it right most of the time, at which point we just do it, and if anyone wants to allocate a different status, fall back on talk page discussion in the usual way. · · · Peter (Southwood) (talk): 20:43, 29 June 2018 (UTC)
Looks good to me. This seems like the best version we've got. @Evad37, Certes, The Transhumanist, Wpgbrown, Waggers, and SMcCandlish: If anyone else has additional input on this, might as well throw it down now. Maybe we should think about cleaning this up and migrating to Wikipedia:WikiProject Portals/Assessment. Or maybe first mention it in the next newsletter, so those who live under a rock can provide input. — AfroThundr (u · t · c) 20:59, 29 June 2018 (UTC)
  • I offered some commentary on this much earlier (before the list of points above was developed) and this is surprisingly close to what I was imagining. I'm good to go with whatever is collectively decided, and if some bit of it doesn't work very well it can be tweaked later. Overall this looks good, though I'm not entirely sure what's to become of the struck parts (are they totally abandoned ideas, or "we're not sure what to put here, but this exact wording isn't quite it"?).

    On transcluding the lead from a B-class article: Check that it complies with core content policies and the content and sourcing guidelines, too, not just MoS (says "that MoS guy"). That's supposed to be done for B-class anyway, but something can migrate a long way from what it looked like when first assessed as B-class, and people are much less apt to watchlist a B-classer than an FA or a GA. Plus, articles are often slapped with a B-class assessment without the checklist that indicates they were examined for compliance with the criteria (In properly done wikiproject talk page banners, I think that prevents actual B-class categorization, but I'm not sure how universal that is). The main issue will likely be addition of unsourced claims, which are hard to detect in the lead, since the lead is citation-free except for controversial claims. I would suggest also treating (by default) A-class and PR-class as identical to B-class for this purpose, because A-class assessment and peer review have both pretty much died on the vine (quite some time ago). There are a handful of exceptions that could be made; I think WP:MILHIST still actively does this stuff, but very few topical wikiprojects are sufficiently "staffed" any longer.

    Back-patting meta comment: I'm quite frankly really impressed and inspired by what's happening here. If you'd asked me a year ago if I thought portals should just be scrapped as a failed, dragged-out experiment, I would have said "yes". This planning and the progress toward making it all practical is exemplary of the wiki spirit, in particular of a happy service-to-readers puppy properly wagging its technological and editorial tail instead of the other way around, and without "drama". It's also one of the few examples I've seen in a long time of a new wikiproject actually doing something useful and fomenting constructive activity (instead of acting as a barrier to participation, and a canvassing/ownership farm for PoV pushers). Kudos all around.
     — SMcCandlish ¢ 😼  23:03, 29 June 2018 (UTC)

I don't think we want to be too focused on what the quality of the articles are, as long as the bits transcluded to the portal are good enough. Maybe having the content come from FA/A/GA articles would making passing of the criteria more likely, but it shouldn't be required. Unless we also want to have some higher rating than "Complete" like "Good Portal". Or perhaps "Excellent" to avoid association with Good Articles which have completely different criteria. - Evad37 [talk] 07:49, 30 June 2018 (UTC)

Some more specific responses:

  • 1a) In general yes, but if the lead of the article is very long, it might be better to transclude only some of the paragraphs.
  • 1b) I don't think that should be part of (1b) -- this is about what sections the portal has in its design, rather than what is going in them
  • 2a) The intent here was that readers purging or coming back to the portal multiple times will see different content. 20 was just a number I plucked out of the air, which might be more suitable for broad topics than niche topics. Perhaps it should beeither: has at least 20 items on random rotation, or a complete set of items on random rotation, or is automatically updated on at least a monthly basis.
  • 2b) I don't think a formal RfC is needed, but other agreed.
  • 3) As long as the transclusion templates are used, or a bot is updating a list, then the portal can't get out of date.
  • 4) Hopefully we can get the portal MOS to a stable state, and from a draft to a passed proposal. I wouldn't expect significant changes after that, given that the premise is that the most of the MOS applies to portals, with specific guidance on what doesn't make sense for portals.

- Evad37 [talk] 08:15, 30 June 2018 (UTC)

Responses to Evad37:
General comment about quality: Agreed, but I think an additional top level classification makes it more difficult to eventually automate, and things will change as articles change and are included in categories and lists by users and bots. My opinions on A-class are somewhat limited, as I have never been involved in the process. B-class mainly opens a huge range of reasonable quality articles for use. No article is guaranteed to stay at the class it is listed, but listed class is the only way I can think of for a possibly automated system of maintenance. Someone else may have a better solution. If so, I would like to see it.
  • 1a} If the lead is too long, it should probably be shortened. Besides that, I am not terribly attached to the number of paragraphs. GA and FA limit them to four if I remember correctly, but there does not seem to be a hard limit to the length of those paragraphs, so four can hold a lot of words. With B-class (or C-class) the problem is more likely to be a shortage of content. I guess we need to decide whether a specific size range is enough justification for having to manually check each article, as opposed to leaving it to some software. If we can have it both ways, great.
  • 1b) OK, but I think it needs to be addressed somewhere. What goes in the sections is as important to portal quality as which sections exist. To be complete, all relevant (useful in context) sections should exist, and each should contain sufficient content of acceptable quality, and there is a lot of scope for variation. If we are too lax with quality of content, the portal may consist largely of poor quality transclusions, If we are too strict, the breadth of content is likely to be too narrow, and these factors will vary as new articles are created, and old articles are improved. We need something flexible, but with acceptably good discrimination.
  • 2a) Your alternative looks workable and flexible.
  • 2b) You are right. RfC is unnecessary unless there is no consensus by talk page discussion, which should do it in almost all cases.
  • 3) Yes, but manual maintenance remains an option.
  • 4) Yes, you are probably right, but who knows? What we are doing now is a major change. One day something similar may happen again. Also new technology may allow more automation, or other unforeseen developments. · · · Peter (Southwood) (talk): 11:06, 30 June 2018 (UTC)
Response to SMcCandlish, On transcluding the lead from a B-class article. There are not enough FA and GA to work without B-class, and in some cases C-class will do if the lead meets B-class criteria. If it doesn't, the article can be downgraded quite easily, based on failing the lead criteria, or alternatively, the lead can be improved so that both the article and portal are improved. Everyone wins. The point here is to get a way for portals to be updated periodically by bot runs, which can list articles by category and quality, and then use those lists to automatically rebuild the portal structure. Whatever looks like it may work should be considered, until we can see why it wouldn't work, and this months failure may work next year. Cheers, · · · Peter (Southwood) (talk): 11:06, 30 June 2018 (UTC)
I understand that and don't disagree with any of it, but it doesn't seem to relate to what I was saying. I was responding 1) to the idea that B-class is only likely to need MoS cleanup, and 2) the unrelated idea that A-class is equivalent to FA for these purposes. B-class pages aren't zealously patrolled, so often contain new unsourced claims in the lead – and they very often do not meet the B-class criteria, because only certain project banners have and check the 6 checklist parameters – meanwhile A-class mostly hasn't been used in years except by a handful of active projects, so similar problems can creep into one. If my skepticism isn't shared, I don't have an real problem with taking all B-class at face value and treating A-class as probably about equivalent to GA. (It seems to have been intended to be about half way between GA and FA, but different projects have approached it very differently).  — SMcCandlish ¢ 😼  15:30, 5 July 2018 (UTC)
Discussion: arbitrary edit break
Comment Perhaps because broken-class portals are likely so underdeveloped that they're equivalent to stub articles, perhaps we should use a word that reflects this? "Stub" portal might seem unusual, but it's better than "Broken." I'd also support organizing them into: "Developed", "Developing", and "Undeveloped"/"Underdeveloped" as portals with such a classification would likely only be used for portals with significant amount of red links. However, I am not sure if simply the development of a portal is an adequate way to assess the overall quality, as a portal may be completely free of red links but have no automation and potentially decay in relevance. I therefore: 1) oppose the name "broken" (though I support having a stub-like classification that suggests the portal needs immediate attention from other editors) 2) support reinstituting the "Featured Portal" system or at least introducing a featured portal category, along with a "B"/"C" rating to differentiate between a portal that is "complete" in the sense that all red links are solved and no templates are missing, and a portal that is "complete" in the sense that it's highly optimized, up to date, reliable, and well-designed 3) recommend that a peer review system for portals is put in place so editors that initially get a poor classification on their portals are not discouraged or believe that no third-party will review their portal again. Brendon the Wizard ✉️ 20:33, 30 June 2018 (UTC)
BrendonTheWizard, Could you then 1). suggest an alternative name for the class of technically broken portals, which specifically includes major coding defects, such as those which cause inappropriate display, and which are not easily fixed, but not necessarily red links, which is more an indicator of an unfinished portal. 2). propose a set of workable criteria for featured portals and B- and C-class portals that will work with automated portals, and with both top level portals and lower level portals.
Peer review can be complex or simple depending on the criteria against which the review is to be done, but anyone can request a second opinion from the project if a talk page discussion of classification does not reach consensus. Straightforward and objective criteria are the best route to accurate and efficient assessment. We have too many portals to fix to spend hours discussing nuanced and subjective details on all of them. Featured portals have a value as an indication of what to aim for, as examples of what we consider best practice, but must not require manual maintenance, either explicitly or implicitly. I would go so far as to propose that one of the FP criteria should be that the portal is automated as much as current tools allow, and to retain FP status, it must be upgraded to keep up with automation developments. Cheers, · · · Peter (Southwood) (talk): 01:24, 2 July 2018 (UTC)
@Pbsouthwood: I would avoid making automation a requirement for high quality portals, as there will always be editors who prefer the older ways, and they are still equally valid. Until we pass an RfC to the effect of "thou shall automate", we should let portals arrive at their destination through whichever path they choose. If the portal get's abandoned, it's obviously free game for automation though. Also, "broken" portals (actually causing problems, unusable) should not even be a class. They should be tagged in {{Portal maintenance status}}, probably with a |broken= parameter, so that it can populate a tracking category for immediate attention. — AfroThundr (u · t · c) 04:04, 2 July 2018 (UTC)
I personally think that the requirement should not necessarily be that it's automated, but that it's up to date and not obsolete. Whether an editor (or a team of editors) maintain the portal, or the portal is maintained automatically, or both is up to the editors, but being up to date should be included in the requirements in some way. I intentionally noted that substantial changes are to be replicated; if the excerpt of an article is featured in a selected content section on a portal, the editors should not need to worry about their portal being demoted because a word or two was replaced in that article's lead; however, if the article's content changes significantly (which can happen through RfCs on its talk page or if an event relating to that article's subject occurs) then it's important to account for this. Brendon the Wizard ✉️ 05:09, 2 July 2018 (UTC)
I appreciate your request and I've drafted a proposal based on other proposals:
  • Featured - Meets all criteria for B-class portals and the former FP criteria
  • A (maybe, but not likely necessary)
  • Good (maybe, but not likely necessary)
  • B - Portal has met all of the following criteria
  1. Complete - The portal has a defined structure. The portal does not have any missing, red, or broken links. The portal contains a summary section and features content. The portal links to related portals and subjects. The portal may still have room for improvement, but it is no longer in its construction phase. The portal is functional and works as intended without errors.
  2. Reliable - The articles prominently featured have no major problems. Information displayed has been reliably sourced on its main article. Articles featured do not currently have any orange warning tags. The text displayed complies with Manual of Style guidelines. The portal and its summary text is stable and not subject to edit warring.
  3. Up to date - The portal is well-maintained either automatically or through regular maintenance. Substantial changes to the articles displayed on the portal page should be replicated. The portal has not become obsolete.
  • C - The portal may partially meet some or all of the characteristics of a B-class portal, but does not sufficiently meet all of them. The portal does not, however, meet the criteria of a developing portal.
  • Developing - The portal is still under construction and needs much work to be finished. Content may be missing or broken.
Any thoughts on this? Brendon the Wizard ✉️ 02:12, 2 July 2018 (UTC)
@BrendonTheWizard: So basically mapping the earlier classes back to more traditional names then? I'm seeing this as "Added FPo, B=Complete, C=Substantial, Developing=Underdeveloped, drop Broken, Portal=Meta-Portal, and unassessed staying the same". Makes sense to me, and as I mentioned above, broken isn't really a class, and FPo is still there for historical (for now, at least) reasons.
I'm still not sold on any of these names for "underdeveloped" or "developing" though. Perhaps just "Start" class would cover it? Anything that fails to even meet start criteria (basic portal functionality) would just be broken or abandoned. New portals that are literally under construction should be tagged as such with {{Under construction}}, since it's also kind of a maintenance status, and could be reflected as such in the project banner, like {{historical}} is. — AfroThundr (u · t · c) 04:04, 2 July 2018 (UTC)
I was very heavily considering just using the word "Start" because the editor truly would be starting their portal if it's thoroughly underdeveloped, has missing content, or has broken links. My proposal essentially merged starting portals and stub class portals, because both would be under construction regardless of whether they were left broken or abandoned or remain unfinished or they're brand new and lack any selected content sections. I'm open to keeping a "Stub" class as equivalent to the proposed "Broken" class (if there is a consensus among others to keep this then I'm not opposed) but I do also like my proposal that merges the Start and Stub classes (in this case, we merge "Stub" into "Start" rather than establishing "Developing" based on AfroThundr's thoughts on the proposal) Brendon the Wizard ✉️ 05:09, 2 July 2018 (UTC)
Start is not a bad description. I would not object to it as a substitute for unfinished, but I think we need to strongly discourage people from starting portals and leaving them in an non-useful state. Particularly non-standard format and manually maintained portals on topics of narrow scope. Unlike an article where a stub is useful, and relatively easy to develop by any editor, a portal that is insufficiently developed is a burden on the system. It is not useful, it is not easy to complete, and it brings antagonism and deletionists down on the whole system of portals, with some justification. If a portal does not serve its purpose, it should not be in portal space. Under construction is OK for a limited period, but when it remains unfinished after whatever that period should be, it becomes a problem to all, as for practical purposes it can be seen as abandoned.
Stub portals should not exist in portal space at all. A stub is a non-portal.
I rather like the proposed new naming system (complete, substantial, sufficient, developing etc), rather than following the article classification system names because it reduces the amount of preconception associated with articles that would be brought into portal classification. (I would liker the article classes to be renamed, but that is not likely to happen soon.) The criteria should not be the same, and using the same names means that people will try to apply the same criteria, either in good faith, from ignorance, or disruptively, because they think they can get away with it, particularly for basically meaningless names like B- and C-class. A more descriptive and different name helps to focus people on the intention of the classification and get them away from comparing with something that they are familiar with, which does not apply but has a similar name.
I dont have any objection to adding Featured Portal onto the top, as it is not a necessary goal. It is the cherry on top for people who have the time and skills to invest in converting from well good enough and completely functional to a fine example of the art. "Complete" should be a realistic goal for all portals, and "Substantial" is where most shoud be. "Sufficient" (good enough) should be the minimum requirement for a portal not under development. I can also accept manually maintained portals as eligible for FP, as it is not my time that would be invested in keeping them there. They may be significantly more vulnerable to demotion - time will tell.
"Complete" implies that all applicable components are present and function correctly. Absence of a component unsuitable for the topic at the time is not a disqualifier. For example, acceptable quality content must already exist in Wikipedia or Commons to poulate a component, for that component to be deemed suitable for inclusion. This may change over time, and if at some stage it exists, the component should be added to make the portal complete again.
I accept that "Broken", "Urgently requires maintenance" or any other name with similar meaning is more useful as a maintainence category than as a class. · · · Peter (Southwood) (talk): 07:37, 2 July 2018 (UTC)
These are all valid criticisms worth taking into consideration, though I still maintain much of what AfroThundr and I have commented. After taking your thoughts into further consideration, I am questioning if the highest non-featured class should be referred to as "B-class" when "Complete-class" portals would actually be at the top of the hierarchy. Perhaps "Good" or "A" could replace "B" which would further demonstrate that the assessment scale for portals and articles are not the same and therefore their criteria is different as well. Here is a draft of what my previous proposal would look like accounting for these changes:
Hold on, we seem to be going going round in circles. The issue with using B/C/Start/Stub is that the names are identical to the article ratings, but the criteria are completely different, which would be confusing. That's why the the names Complete/Substantial/etc classes were proposed. - Evad37 [talk] 09:09, 2 July 2018 (UTC)
Is it not a viable option to state in the criteria descriptions or on the criteria page that we do not use the same criteria as articles, or let the editors know just by virtue of the fact that the assessment page would quite literally contain its own criteria? I ask this sincerely. Brendon the Wizard ✉️ 10:08, 2 July 2018 (UTC)
We seem to have ironed out the criteria, with just the names themselves still up in the air. It appears we're looking at traditional names - "B", "C", and "Start" - vs. new names - "Complete" (or good?), "Substantial" (better name?), and "Developing" - for these classes. Either naming convention would honestly work. If we adequately documented our criteria on our assessment page, that should suffice for a majority of editors. However, there will still be those who don't bother checking it - but then, no amount of documentation will help them anyway. The best case in that situation would just be to watch the assessment categories and double-check them whenever a non-project member adds a rating to a portal. I like the traditional classes because they're consistent with existing assessment nomenclature, but the new names do have merit, and would set portals apart. — AfroThundr (u · t · c) 12:52, 2 July 2018 (UTC)
What I see in this latest table actually illustrates my point. The class named "B" is then described as "Complete" and "C" is described as "Substantial". What Evad37 proposed is basically to cut out the middleman and just name them by their primary descriptive term, ie. that which is described as complete, should be called "Complete", and that which is described as substantial, should be called "Substantial" This seems logical, and should be easy to remember, and difficult to confuse with article class criteria.
It may be a small matter, but the existence of B and C tends to suggest the existence of A, and I don't think anyone really wants A class for portals.
I prefer Complete to Good. It explains why it is good. Substantial is intrinsically more meaningful than C, which suggests nothing more than the third level of quality, without any reference to how good or bad it is. A, B and C are more likely to drift in meaning than Complete, Substantial and Sufficient. It is easy to redefine A, B and C gradually, but Complete, Substantial and Sufficient are more resistant to creep in either direction, which would make them more stable, They also have antonyms, which could be useful for suggesting when a portal no longer belongs in a class - when it is incomplete, insubstantial or insufficient. not-B and not-C don't have the same immediacy. We are not that short of space that the length of the word should be an issue. Developing also says what it is, though start is not too bad. Developing implies a dynamic condition, moves up to developed, or down to underdeveloped or abandoned, which are also suggestive of how to deal with the new status. Start can stand there spinning its wheels indefinitely, stall, or move ahead, but to what? arrived? (seriously though, I don't mind start if others prefer it to developing). These descriptive classes may also help with people who don't bother to read the instructions because they think they know them already. Cheers, · · · Peter (Southwood) (talk): 19:12, 2 July 2018 (UTC)
Though I'm still unsure whether or not the issue of editors confusing the article criteria with portal criteria would be great enough that it is necessary to change them, after much consideration there doesn't need to be an issue to warrant giving portals their own unique criteria. As much as I do still like the familiar traditional class names of Start, C, B, etc, I don't actually see any downsides to the new names and I don't want to be a voice that prevents a consensus on a much-needed quality assessment scale over a detail as small as whether to call the class "B" or "Complete." I am unopposed to the proposal that replaces class names with the new names, but I will reiterate my concern regarding the proposed "Broken" name and I would continue to recommend that a "Start" class equivalent ("Developing") is the lowest class, as any portal that cannot warrant at least a start class likely should not be in mainspace. Brendon the Wizard ✉️ 19:34, 2 July 2018 (UTC)
Maybe we can lay the broken class to rest. Does anyone still think that "Broken" or an equivalent is useful as a class for portals? I don't. I think a maintenance category would be useful, so portals with unsuitable code can be identified for fixing, because broken code does not necessarily indicate the quality once it has been fixed, which could be featured through to non-portal. · · · Peter (Southwood) (talk): 15:19, 3 July 2018 (UTC)

Keeping it positive

On retrospect, it might be best to use positive or neutral descriptors, rather than ones that can be presented as criticisms such as "underdeveloped" and "broken". Any word that could be used as a synonym for "crap". Otherwise, we may be shooting ourselves in the feet. Imagine a new RfC that states "There are 899 underdeveloped portals and 162 broken ones, and therefore, we should get rid of portals." Besides that, we don't want a portal's rating to be the justification for a deletion discussion. "Delete this portal, because it is broken."

"Underdeveloped" sounds very similar and is semantically related to one of the speedy deletion criteria for portals: WP:P2, underpopulated. We wouldn't want them to get confused.

"Broken" was initially intended to identify portals with formatting errors, signifying a broken page. Portals needing immediate attention, because they aren't rendering correctly on the page. Though "broken" sounds really bad. Perhaps "Needs immediate attention" could work, as long as its description is very clear and not broadly subjective. That sounds more like an alert than a criticism, and would therefore be more appropriate. Whatever this rating is called, its corresponding category could play a crucial role in portal maintenance, helping to ensure that the worst problems are treated urgently. This would be a category our vigilant WikiProject troubleshooters would watch closely.

Concerning descriptions, I believe "abandoned" is not a measure of a portal's quality, though it may be a contributing factor (especially for manually maintained portals). Who is or is not involved with a portal's maintenance should have nothing to do with the rating. An "abandoned" automated portal could remain relevant for years, with no editor interference, if done right.

Thoughts?    — The Transhumanist   04:28, 30 June 2018 (UTC)

I agree that "abandoned" isn't a quality measure – the real measure is whether the material is outdated (i.e. #3 of the criteria), which it won't be if it is automated, but likely will be if it is manual. As for more positivity, maybe "Basic" instead of "Underdeveloped"? and perhaps "Broken" shouldn't even be a class – instead we can have an |attention=some reason parameter on the project banner that adds both a category and a "requires immediate attention because: some reason" note. - Evad37 [talk] 07:39, 30 June 2018 (UTC)
When I used the word "abandoned" I was thinking of portals that appear to have been abandoned part way through construction. There are quite a few, and they are generally not pretty or useful. A complete portal, as you suggest, or even a substantial one, should only need work when new features become available, or to polish it up a bit. However, manually maintained portals can also be abandoned and slowly drift out of date and out of contact with reality. There should be some way to rescue them, but it will probably mean converting to a standardised automated structure by the rescue party, and this should be allowed if they are actually abandoned.
While on the subject, it might help if each portal with a dedicated maintainer or group of maintainers gets a notice on the talk page indicating who they are, so anyone who is considering making a significant structural or style change can notify that group. Maybe {{Portal maintenance status}} could be amended to use the |manual= parameter to list the dedicated maintainers.
How about incomplete, under construction or unfinished in place of underdeveloped? Under construction has the most positive spin, and may encourage the constructor to get on with it, but how long before is is considered abandoned? What is the meaning we want to associate with the class of portal? To me this is any portal which does not yet comply with minimum standards, which we have yet to define, but would probably mean meeting all the reasonably applicable strongly recommended requirements of the portal guidelines. Basic would imply that the portal meets minimum requirements. It might be a useful additional class.
This would imply that substantial is anywhere between minimum acceptable (basic) and complete
What word would work as a description for a portal in which the code and/or appearance are not compliant with any reasonable standard? This is to differentiate from those which are simply unfinished, but what is there is acceptable in layout and quality of code. Needs urgent attention or similar gets the message over, but is a bit wordy. That is not a disqualifier, just a wish for something shorter.
We need to manage the issue of accessibility somewhere. Some box headers are not easy to read due to bad colour combinations. If we standardise a set of box headers with good accessibility, then we go some way towards sorting out that issue. I am not suggesting that such a set be the only options allowed, but it makes it a lot easier to choose a good option. · · · Peter (Southwood) (talk): 12:11, 30 June 2018 (UTC)
@Pbsouthwood: you may be interested to know that a |maintainer= parameter was added to {{portal maintenance status}} earlier today by Wpgbrown. We're all set on that front. — AfroThundr (u · t · c) 21:02, 30 June 2018 (UTC)
I just added a note using the existing parameter, but maintainer may be more useful in the long run as it can be used to categorise if needed. I will switch over. Things sure happen fast in this project! Cheers, · · · Peter (Southwood) (talk): 07:14, 1 July 2018 (UTC)
I see that my use of the "note" parameter is more appropriate, as "maintainer" rightly refers to manually updated portals, and I am trying to automate to the limit of available tools. · · · Peter (Southwood) (talk): 07:22, 1 July 2018 (UTC)
@Pbsouthwood: Do you think, perhaps, that we should leave |manual= and |maintainer= separate? That way "hands-off" maintainers of automated portals could still be listed. I think that tracking manual vs auto independently of listing maintainers might be a use case we should cover. @Wpgbrown: Thoughts? — AfroThundr (u · t · c) 19:17, 1 July 2018 (UTC)
As long as it is not seen as a way to claim ownweship of a portal by the maintainers, more a notification to take care about making major chnges without discussion, to minimise surprise, I think it could be useful to heve both. If there are no maintainers for a portal, it should be acceptable for anyone to convert it to automated code without further discussion, If there are maintainers, BRD should still apply, but at least one can have an idea of where someone might legitimately revert - where there are one or more maintainers registered. This is mainly relevant while we are doing major upgrades to the whole system. I see no downside to an additional parameter beyond the effort of putting it in, which is trivial. Bermicourt maintains several portals, and may have comment on this. · · · Peter (Southwood) (talk):
Very good general point. Not sure I feel terribly strongly about suggested rewordings. "Basic" sounds good for "Underdeveloped". "Under construction" describes everything in Wikipedia, and it's also has a bad rep (think of how many times you've seen an icon that says that on a webpage that hasn't been updated since 2002). Maybe "Needs attention"? We needn't have long labels. Dunno about "Abandoned"; "Unmaintained", maybe?  — SMcCandlish ¢ 😼  18:03, 30 June 2018 (UTC)
I don't know if anyone is proposing "abandoned" as a category, class, or quality. I was just using the word to describe portals that have been half done for years. It is more a reason for the quality than the actual quality I was referring to earlier as broken. Unmaintained is not of itself a problem. An unmaintained portal could just be complete and not need any maintenance. An unfinished portal clearly needs to be finished, a basic portal is OK, has room for improvement, but no urgency. The one which needs repair urgently is the one for which we need a word other than "broken". · · · Peter (Southwood) (talk): 18:20, 30 June 2018 (UTC)
I support the idea that, where there are maintainers of portals, this should be noted somewhere. We've already done this on the portal page and I think it's helpful to know that someone has volunteered to maintain a given portal so that if we have questions or want to improve a portal, we can contact them. It's not about ownership, it's about cooperation. As the creator and maintainer of a couple of dozen portals (mostly by translation), I can explain how they work, why they were set up in a particular way and what needs doing from an informed perspective. Also if I'm going to continue to maintain them, I'd appreciate understanding the changes so I can continue to support them. Most of the changes to date have been good, but I've had to revert at least one where the same template was added to the main page and a subpage resulting in it displaying twice. Also some of the templates have cool ideas or sub-templates in them which might have wider applicability. Maintainers can flag those up for further discussion and possible adoption elsewhere. HTH. Bermicourt (talk) 06:24, 2 July 2018 (UTC)
Thanks Bermicourt, This is the sort of thing I had in mind, just expressed more specifically. Cheers, · · · Peter (Southwood) (talk): 06:43, 2 July 2018 (UTC)
@Bermicourt: See the new |maintainer= parameter of {{Portal maintenance status}}. — AfroThundr (u · t · c) 12:21, 2 July 2018 (UTC)
Cool, thanks team. Bermicourt (talk) 12:29, 2 July 2018 (UTC)

A possible compromise

This version uses the terms that are less likely to be confused with article classes, and avoids the terms that may encourage deletion tagging. Colour coding looks reasonably appropriate. The criteria may require further tweaking, but I think they may be close enough to run with. · · · Peter (Southwood) (talk): 16:31, 14 July 2018 (UTC)


So about the "Basic" class - I'm thinking "Start" best reflects the nature of that class, and "Sufficient" just doesn't work as well. If we want to avoid the standard names completely, we'd want to go with "Basic" though. As for the "Incomplete" class - another synonym would be "Draft", but like "Start", we probably want to move away from that. From the last two, I think "Incomplete" would be best, as "Underdeveloped" implies basic level functionality that just needs improvement. Besides the nit-picking over the names, the rest looks good to me. — AfroThundr (u · t · c) 17:31, 14 July 2018 (UTC)

What does ListPages.js do?

The title makes me wonder if this might have something we could use, but I can't figure out how to get it to work, or even what it does: User:Dr Brains/ListPages.js.

The doc is no longer around, and didn't leave any instructions behind.

What does it do, and how does it work?    — The Transhumanist   23:45, 4 July 2018 (UTC)

Looks like it was intended to get all articles in a category, including all subcategories, and then find each article's interwiki target on the French Wikipedia, and produce a table of articles and their French equivalent. But it is using outdated/deprecated techniques, which would be why you can't get it to work. - Evad37 [talk] 05:31, 6 July 2018 (UTC)
Thank you. I'll cross this one off my list.    — The Transhumanist   07:58, 8 July 2018 (UTC)
A tool to get all articles in a subcategory, including all subcategories, and list them in that structure, would be quite useful. · · · Peter (Southwood) (talk): 08:36, 14 July 2018 (UTC)
You can use wp:PETSCAN to do that (and a whole lot more) - Evad37 [talk] 11:29, 14 July 2018 (UTC)

Converting the intro sections

Thank you for updating editors on this. I know it doesn't currently apply to manually maintained portals, but I just wanted to say that I'm going to try and convert the intros for the 30 or so portals I maintain. It's worked on two so far, with a bit of tweaking. Thank you to those who worked out how to do it! Bermicourt (talk) 20:06, 10 July 2018 (UTC)

Bermicourt, We will generally not make this sort of change to a manually maintained portal out of deference to the maintainer, who has taken on the task of doing the maintensnce and any upgrades themself. If you have any trouble doing the upgrades, leave a note somewhere and we will try to help sort it out. We encourage maintainers to use the automated tools whenever there are no good reasons not to do so, because it is less work in the long run, and there is less risk of content forking when using transcluded excerpts. Cheers, · · · Peter (Southwood) (talk): 07:02, 14 July 2018 (UTC)
Pbsouthwood. Thanks, very happy with that. I'm generally a fan of automated tools; I created one to cycle through articles/images of the month when transferred a portal from German Wikipedia but realised I wasn't going to get the support they have there to create new articles and images every month. So I set them up with an annual cycle of 12 articles/images. Clearly the frequency and cycle period are changeable. Cheers. Bermicourt (talk) 07:13, 14 July 2018 (UTC)
P.S. I think it's good, though, that you aren't forcing the changes on portals that are manually maintained as you will retain the goodwill of those maintainers. :) Bermicourt (talk) 07:14, 14 July 2018 (UTC)
That is the intention. If anyone wants to use the new toolkit we are willing to assist, if they don't, they are more than welcome to do it a different way as long as it works. We will convert portals with no known maintainer (most of them it seems), and if someone pops up and claims to be the maintainer then they can revert and carry on from there, as long as they actually do the maintenance they volunteer for. If they don't, someone may tag for deletion as unmaintained/out of date/whatever, and then we consider the portal open for conversion. The enthusiasm and support for automation here is amazing. We want people to join us when they think our way is better, and if they think they have a better way, to develop it so we can join them if it works. Cheers, · · · Peter (Southwood) (talk): 08:23, 14 July 2018 (UTC)

Slideshow failure mode on mobile devices

Someone from the project edited my test portal with the summary "Rename Picture slideshow section to "Selected pictures", because it doesn't show up as a slideshow on mobile devices" -- does anyone know what the failure mode on the slideshow is for mobile devices? (I don't own one, so can't check.) I was assuming that I'd have to convert the slideshow to the random subpages model before going live on this one, but I've been putting it off as I like the functionality. Espresso Addict (talk) 08:24, 12 July 2018 (UTC)

The gallery shows up as a standard gallery instead of a slideshow. You can check the mobile version on a desktop device by going to the version of the page, e.g. - Evad37 [talk] 09:11, 12 July 2018 (UTC)
See also Wikipedia talk:WikiProject_Portals/Design § Slideshows and the mobile skin - Evad37 [talk] 09:13, 12 July 2018 (UTC)
Thanks; I didn't know I could look at the mobile version like that, handy! Espresso Addict (talk) 09:32, 12 July 2018 (UTC)

Problem with automated presentation of content on Portal:Reptiles

Bit of a problem on Portal:Reptiles, 7 boxes relying on automatic presentation of content are now saying "The time allocated for running scripts has expired." Sincerely, InsaneHacker (💬) 09:12, 15 July 2018 (UTC)

@InsaneHacker: I am currently unable to reproduce the issue. None of the templates on that page are currently misbehaving AFAICT. If the problem is still occurring for you, please open the HTML page source and look for a comment block similar to the one mentioned here, then post it here so we can find the culprit. — AfroThundr (u · t · c) 16:11, 15 July 2018 (UTC)
The problem is not occurring for me either anymore. Perhaps the backend was having some issues this morning. Sincerely, InsaneHacker (💬) 16:26, 15 July 2018 (UTC)
I have also seen the problem in the last 24 hours (can't remember exactly where or when) but it seems to work now. Certes (talk) 18:01, 15 July 2018 (UTC)
@InsaneHacker, AfroThundr3007730, and Certes: It seems to happen when a super large pic is being displayed. I was running into this phenomenon with the panoramic pics being added to the intro sections, and found that it went away when I found smaller-sized pics (under 2 megabytes) to display instead. Some of the pics in slideshows might be huge, but would only cause the problem when they are displayed, making the problem intermittent. That's where I would look next. If you purge the page, and the problem goes away, it was probably a large pic in the slideshow.    — The Transhumanist   03:51, 18 July 2018 (UTC)

Introduction automation

Hi, in the automation of the introduction section to portals we are loosing images or maps, as these are usually in the infoboxes and so the template replacement does not extract the image or map for the portal. Is there a way of overriding this to enable an image or map to be placed in the introduction or should the automated process be extended to include detail from the infobox? Keith D (talk) 18:48, 15 July 2018 (UTC)

This is template being used Template:Transclude lead excerpt. The image parameter is files=. It however doesn't include images in infoboxes. --Emir of Wikipedia (talk) 19:11, 15 July 2018 (UTC)
The template attempts to include images from infoboxes. Is there a particular portal where it's not managing to do that? Certes (talk) 19:38, 15 July 2018 (UTC)
The documentation says "Note that images within infoboxes etc. are not available." Emir of Wikipedia (talk) 21:15, 15 July 2018 (UTC)
Thanks for spotting that. The documentation was outdated; I've fixed it. It is still possible for an article to display an image in an unusual way which the template fails to detect. Perhaps the infobox in the relevant article uses such a technique. Certes (talk) 21:37, 15 July 2018 (UTC)
I was looking at Portal:Lincolnshire which had a map before conversion and nothing after. Though the image used for the map is not in the infobox on the Lincolnshire article but a map is there that could be used. Maybe a |file= parameter is needed to code in an image which is not from the article. Keith D (talk) 00:31, 17 July 2018 (UTC)
It used to use Portal:Lincolnshire/intro/2 (or, randomly, the flag in /1), which in turn uses Portal:Lincolnshire/intro/layout. That's probably best done manually, by adding a File: to the main portal page, rather than by coaxing the excerpt to include an image that's not actually in the article. Certes (talk) 01:00, 17 July 2018 (UTC)
As an alternative, you can add thumbnail pics to the top of the box, and they will be floated next to the text as usual. You can also add a panorama, which will display before the text. For examples of panorama insertion, see Portal:Seattle, Portal:Munich, and Portal:Miami. For the panorama insertion task, see Wikipedia:WikiProject Portals#Add a panorama or skyline to a geographic portal.    — The Transhumanist   04:06, 18 July 2018 (UTC)
@Keith D and Emir of Wikipedia: Evad and Certes have been improving the image detection capability of the transclusion templates. For details, and to report an image that is getting missed, go to Wikipedia talk:WikiProject Portals/Design#Template:Transclude lead excerpt.    — The Transhumanist   05:00, 18 July 2018 (UTC)

Update from Member

Hi , I have some news here .

Firstly , I have added panoramas to Portal:Calgary , Portal:Moscow , Portal:New Orleans and Portal:Brisbane .
But something is wrong with Portal:Melbourne , please can somebody check on it ? Kpgjhpjm 12:42, 16 July 2018 (UTC)
It's getting the "The time allocated for running scripts has expired." message on {{Transclude lead excerpt|Melbourne}}. Purging didn't help. Melbourne is a long article. I'll see whether we can handle large pages more efficiently. Certes (talk) 15:03, 16 July 2018 (UTC)
@Kpgjhpjm: Fixed. The caption text for Melbourne's map also appears earlier in the infobox as alt text, which confused the parser into an infinite loop. Sorry for the inconvenience; thanks for the report and for adding the attractive images. Certes (talk) 16:04, 16 July 2018 (UTC)
@Certes: Added panorama to the Portal along with Seattle and Houston portals . Kpgjhpjm 16:33, 16 July 2018 (UTC)
Retrieved from ""
This content was retrieved from Wikipedia :
This page is based on the copyrighted Wikipedia article "Wikipedia talk:WikiProject Portals"; it is used under the Creative Commons Attribution-ShareAlike 3.0 Unported License (CC-BY-SA). You may redistribute it, verbatim or modified, providing that you comply with the terms of the CC-BY-SA