These are likely the most powerful tools available to Wikipedia editors. We need you up and running with these ASAP. If you use Windows, you'll be using AWB. JWB otherwise.
Yes I am using JWB to add short descriptions at the moment and it does help cut down the number of clicks needed. I will make a point to check out the AWB option. JLJ001 (talk) 22:11, 27 May 2018 (UTC)
Um... no. I just typed my username into the field that grants "full dev access", that seemed to do it. JLJ001 (talk) 22:17, 27 May 2018 (UTC)
Ah, a JWB fork. Impressive. I think it's best you get registered with AWB ASAP, and your use of JWB will be covered. Besides, there are many things AWB can do that JWB cannot. Let me know when you are registered. — The Transhumanist22:36, 27 May 2018 (UTC)
I may file a bug report for JWB to get them to hide that glaringly obvious "backdoor". But in the meantime I have to applied to correctly register for AWB. Perhaps I can be one of the "rare" approvals. (I have 20 edits to mainspace). JLJ001 (talk) 22:40, 27 May 2018 (UTC)
It would seem that if we abide strictly by the posted AWB selection criteria of
Users with under 250 non-automated mainspace editsor500 total mainspace edits are rarely approved
Neither myself or JLJ001 would qualify, even though we both have quite a few edits.
No. But, since it can be used there, where it could potentially do the most damage, they require main namespace experience. — The Transhumanist22:34, 27 May 2018 (UTC)
I won't make 500 minor edits to mainspace just to meet that limit unless absolutely necessary. But I guess I could add portal links to a bunch of articles if necessary. JLJ001 (talk) 22:42, 27 May 2018 (UTC)
@JLJ001: The sooner, the better. We are gearing up to do some major maintenance runs on the portals (many passes on the 1500), along with subpage tagging. When we get up to speed, we'll be tagging 140,000+ subpages. We may also be processing navigation templates to check for and add portal links where they are missing. — The Transhumanist23:14, 27 May 2018 (UTC)
I suppose it wouldn't be difficult to generate a couple hundred legitimate mainspace edits to meet the requirements (there are plenty of maintenance categories to tackle) but I don't think that should be necessary. If you think it has any probability of success, I'll submit for access anyway. — AfroThundr(t•c)22:51, 27 May 2018 (UTC)
My application to get on the checkpage is not going to go through until I make 500 mainspace edits. @The Transhumanist: is it possible to add an image to {{Portal|Suffolk}} ? perhaps "County Flag of Suffolk.svg" JLJ001 (talk) 09:00, 28 May 2018 (UTC)
I know a bit. I tinker with a lot of things so I know a bit of everything. Although I wouldn't bet my life on my coding skills in any particular language. — AfroThundr(t•c)22:53, 27 May 2018 (UTC)
Good. Because, to fully automate portals, we are eventually going to need bots to do a portion of it. Leading up to that, we'll need semi-automated tools, such as in assisting editors in creating portals. For example, the user specifies a category, and the tool fetches the article titles from the category and inserts them into the transclusion template. Things like that.
I encourage you to join WP:JS, and familiarize yourself with the resources there. Especially the Wikipedia bots written in JavaScript, collecting the source code for those for which it is missing, if possible:
I have been thinking that in addition to the obvious need to build a bot which updates selected article sections automatically. There is also scope for a report bot. JLJ001 (talk) 14:39, 29 May 2018 (UTC)
Interactive maps
Map
Relaying from WP:India Noticeboard.
The Kartographer extension is now available.
Note: The following notice was placed on over 1000 WikiProjects (with portals that fall under their subject)
The reason I am contacting you is because there are one or more portals that fall under this subject, and the Portals WikiProject is currently undertaking a major drive to automate portals that may affect them.
Portals are being redesigned.
The new design features are being applied to existing portals.
At present, we are gearing up for a maintenance pass of portals in which the introduction section will be upgraded to no longer need a subpage. In place of static copied and pasted excerpts will be self-updating excerpts displayed through selective transclusion, using the template {{Transclude lead excerpt}}.
Maintainers of specific portals are encouraged to sign up as project members here, noting the portals they maintain, so that those portals are skipped by the maintenance pass. Currently, we are interested in upgrading neglected and abandoned portals. There will be opportunity for maintained portals to opt-in later, or the portal maintainers can handle upgrading (the portals they maintain) personally at any time.
Well, good luck. You're (even more obviously than others of us) shoving water uphill with a rake, pushing string through keyholes, and coaxing camels through the eyes of needles (now there's a thought). I also think it pointless, unless you can quickly demonstrate actual readership. Chiswick Chap (talk) 08:52, 30 May 2018 (UTC)
Along with the gems, there were some awful portals out there, and a few still remain. I don't blame people for not reading the old versions, but this project is about producing a more attractive replacement. If you build it, they will come. Certes (talk) 09:32, 30 May 2018 (UTC)
Chiswick Chap, while I agree that WikiProject Portals has taken on a mammoth task, it is not an impossible one. I have never understood the argument for deletion of portals on the basis of low readership. That's never been applied as a criteria for deletion of articles. Portal:Opera has had on average 30 readers a day over the last 90 days, far more than many articles on highly notable figures in their day who have entries in both general and music encyclopedias, e.g. Nicola De Giosa, which has had on average 1 reader per day over the last 90 days. Likewise, essays in Wikipedia space are not deleted for low readership. Even defunct WikiProjects are kept as historical documents. There may be quite valid reasons for deleting some portals, but low readership isn't one of them. Just saying... Voceditenore (talk) 11:09, 30 May 2018 (UTC)
The time for debating deletion has passed: that's history. The risk now is the Concorde fallacy, that so much effort has been spent on building this thing that it must be worth spending more until (maybe) the thing eventually starts working. It isn't, and (I'm happy to predict) it won't. That's testable of course, come back in a year or two and show me how well it worked—or didn't. Chiswick Chap (talk) 11:43, 30 May 2018 (UTC)
But, Chiswick Chap, presumably you think the number of portal readers will be the test of the success or otherwise of the current drive. Or did you have other criteria in mind? Voceditenore (talk) 12:39, 30 May 2018 (UTC)
You are very persistent. Yes, the number of genuine readers who may be presumed actually to be benefiting in some way, however small, is the measurable criterion I mean. Success will mean a marked increase, both in percentage terms (not difficult, but not very useful if you increase readership from 3 to 5 per annum) and in absolute numbers. We can see that an article like Aristotle is meeting a need from its millions of views each year. You do the same for the portals, and everybody will agree with you. Chiswick Chap (talk) 13:05, 30 May 2018 (UTC)
It's not traffic volume that we are trying to improve, but user experience and support. Keep in mind that Wikipedia's navigation systems are not intended to compete with external search engines, but rather to complement them. I'm guessing that around 95 to 99 percent of searches on Wikipedia take you right to where you need to go. That system doesn't need replacement. But, when search proves inadequate for finding what you are looking for (like when you are not sure exactly what it is you are looking for), that's where our supplemental back up systems come in. They are extensions to the search system, to push finding effectiveness closer to 100%.
Because of this, comparative traffic is not a meaningful measure of the performance of the navigation departments. They will never come close to the traffic volumes that flow through search engines, which are the most effective tool type for basic searches. The thing we need to know is how well these systems perform when search engines do not. They are intended to catch the people who fall through the cracks when their search strings fail to match.
When a person is on a deadline, and they are at their wits' end on finding particular details, do the navigation systems help that person find what they need when search fails? If so, then they are well worth it. When a person wants a general overview of everything on Wikipedia about a subject, do they find our navigation systems pages more useful than the search results page? If so, then they are well worth it. When a user experiences Tip of the tongue phenomenon and can't think of the term they want to look up, do our navigation systems help them spot it? If so...
So, the main question is, would people rather have an encyclopedia with one way to find info (search) or would they want one that has search plus browsing-based systems to help in the rare cases that search can't quite cut it? It's the "plus" (quality, valuable service) that we focus on. Going the extra mile to provide the features users need when they need them. And now that we are building automated methods into this, the cost in editor resources shouldn't be that high. A portal that took days to build, now takes a little over an hour, and we're likely to get this down to under 10 minutes. We are also designing a low-maintenance model, and once a portal is built using it, the portal will essentially maintain itself.
I respect the passion, but fear, indeed am sure in my bones, that it is misplaced; but I wish you all well with your project. There are two reasons: experience - most existing portals have languished, their enthusiasm long dried up for want of a following; and Google: there's a portal-and-a-half. People find articles by searching or by following links, either via Google or from the Wikipedia app or front page. As for user numbers, there's no point providing a wonderful experience for people who don't visit, so numbers do matter. Chiswick Chap (talk) 08:16, 31 May 2018 (UTC)
Bien dit! I knew there was a reason we chose you as our PR manager. You just about made me want to sign up again. — AfroThundr(t•c)22:04, 30 May 2018 (UTC)
The above message mentions adding your name as a "portal maintainer" if you don't want automated updates to take over your active portal. Fair enough. So when I looked at the linked page, I see tons of maintainers! Great! Except... the first one I looked at, the PlayStation portal, has Effer as the maintainer... who hasn't edited more than once a year since 2013, and hasn't edited the portal since 2007. And who added their name to the maintainers list in 2006. If y'all are going to be using that list to make decisions on what portals are actively managed, you should maybe clear it out first. --PresN16:27, 31 May 2018 (UTC)
With more automated portals the necessity for maintenance will reduce. If a user who claims to be a portal maintainer does not respond to a portal talk page ping, and they have no Wikipedia activity for 3 months and there is no user talk page notice indicating that they are on a wikibreak, it would be reasonable to conclude that they are no longer an active maintainer. A final check could be to email them if it is possible and ask.· · · Peter (Southwood)(talk): 12:04, 2 June 2018 (UTC)
Suggestion for a portal
Comment Not sure where to put this comment, here seems as good a place as any. A number of times in the past I have commented that if there is going to be a Portal:Pornography and a WP:WikiProject Pornography then there ought to be Portal:Anti-Pornography and a WP:WikiProject Anti-Pornography to satisfy NPOV. I usually get either a deafening silence or a gritted-teeth "sounds like POV pushing to me" - a truly bizarre answer considering that's exactly the problem that the creation of such a portal/project seeks to address. --The Vintage Feminist (talk) 23:26, 1 June 2018 (UTC)
I agree with Certes, A portal is a way to access articles about the topic. Anti-pornography is about pornography. Portal Pornography should not be a link to pornographic articles (we should not have any), but any articles about the topic. However, more focused portals are fairly common, and if there are anough articles about Opposition to pornography, there is no obvious reason why there should not be a portal for it if you want to create one. · · · Peter (Southwood)(talk): 11:47, 2 June 2018 (UTC)
Huh, these WikiAds are neat. I hadn't noticed them because my ad blocker's cosmetic filter stripped them. — AfroThundr (u · t · c)15:31, 2 June 2018 (UTC)
Great idea. That seems good to me: the message and graphics are very clear. The one thing I'd change to see if it looks better with a different font, though sadly I don't have a more concrete suggestion. Certes (talk) 15:37, 2 June 2018 (UTC)
Does Wikipedia unknowingly present itself as a thesaurus when presenting an articles content...
...That Wikipedia knowledge is a noun, but as presented, is a verb relating one's state of being as Wikipedia knowledge...
Should it be Wikipedia's work to present it's self through Socratic methods...
...Does Wikipedia need a Philosophy of Wikipedia Article...45.49.226.155 (talk) 19:00, 2 June 2018 (UTC)Arnold45.49.226.155 (talk) 19:00, 2 June 2018 (UTC)
An excellent visual aid to the various templates avalable for automation. Also handy as a checklist when reviewing or improving existing portal layouts. Well done. Cactus.man✍12:46, 3 June 2018 (UTC)
Hi Afro, I have 3 portal-related subpages, one of which is for my own housekeeping; the other two are English copies of German Wiki portal project pages which I translated because I felt they might be of use (albeit adapted) for our project. I've referred (and linked) to them a couple of times during discussions. But I wouldn't want to move them to mainspace without a consensus and appropriate tweaking. Their status is as follows:
User:Bermicourt/Portals - is for my own housekeeping. It lists the portals I maintain and their status. Also has a table showing the rough equivalence between English and German Wiki portal pages.
User:Bermicourt/Portal status - is a copy of how German Wiki evaluates portal status using a traffic light system and listing their assessment criteria. We could use something like this.
User:Bermicourt/Portal/Overview and Relevance - is a copy of how German Wiki decides whether portals are relevant - which ones can be created without consultation and which ones need discussion and support before being created. Again we could do something like this.
@Bermicourt, The Transhumanist, Cesdeva, Certes, and Wpgbrown: and everyone else, I've noticed that several of our subpages are redirects to pages maintained in Bermincourt's userspace. I'm thinking that if we're going to link them as subpages, we might as well move them into our project space directly. I like what I'm seeing here and I think these might be useful for adoption. Thoughts? — AfroThundr (u · t · c)13:22, 4 June 2018 (UTC)
Thank you for digging out these useful words. As User:Bermicourt/Portals lists User:Bermicourt's portals, I think it is already at the right title. The other two can be seen as essays. They could stay in user space but, as they're community views rather than personal statements, it might be better to move them into WP: namespace. Certes (talk) 13:32, 4 June 2018 (UTC)
They are community views from a different community. They might also be views of this community, but this would first have to be established. They provide a useful reference where they are, but I think that the ideas should be discussed and imported here as and when each is accepted locally. · · · Peter (Southwood)(talk): 05:53, 5 June 2018 (UTC)
I also think these pages should stay in userspace, but we should look at adapting the ideas into our own existing guidelines/pages. The traffic light system could be adapted into Wikipedia:WikiProject Portals/Assessment's class assessments (maybe as stub-/start-/C-/B-class portals); and the Overview and Relevance might be relevant to proposed rewrites of WP:Portal guidelines and related pages. - Evad37[talk]13:46, 4 June 2018 (UTC)
I agree with Evad37 in general principle. There are ideas that are worth cnsidering, but I think the final results will be different in detail, and possibly some concepts will end up different. Good as a reference. · · · Peter (Southwood)(talk): 05:46, 5 June 2018 (UTC)
For completeness, copyright attribution and good housekeeping, I've added the detailed German Wiki source information for pages 2 and 3 at the bottom of each page. The source info is then readily available if we want to incorporate any of it into Portal space. Bermicourt (talk) 16:52, 4 June 2018 (UTC)
Comedy is art
Why is there no portal for comedy within the arts portal? Surely they are one in the same.
Stand-up comedy specifically aswell as humor in film could easily be discussed.
This project has too many talk pages with hair-splitting distinctions. It's confusing and unhelpful, especially since the Wikipedia talk:WikiProject Portals is an empty soft redirect to a confusing array of topical but overlapping pages.
One of the surest ways for a wikiproject to gradually go moribund (sometimes quickly) is excessive decentralization and splitting of human resources. We've seen this many times, e.g. with unnecessary workgroups/taskforces being created then going moribund but people not watchlisting the main project page, so it becoming inactive eventually, too; and dozens (at least) of "/Assessment" and "/Peer review" process pages no one has used in years.
After the initial flurry of this project's activities to make various tech stuff possible and get design and policy stuff implemented – as soon as the traffic becomes manageable, if it isn't already – all the project talk pages should eventually become one, unless there's a continued good reason for some kind of split. It's important to remember that a wikiproject really doesn't consist of do anything other than direct editorial collaboration and communication, plus some support templates and stuff, so splintering into microtopics is antithetical to the goals.
Merge all – One talk page, please. That way, all project-related discussions can be monitored via that one page's history. Having to do it 5 times (or even 3) to spot all the new traffic is a bit much. This also means we'll have one set of archives, rather than 5. One is sufficient for our message traffic volume. — The Transhumanist20:49, 30 June 2018 (UTC)
I don't feel strongly that "omnipage" needs to happen right this moment. I wasn't sure if it was true yet that the volume was low enough; I didn't want to "forcibly" commingle Q&A material, and policy/guideline talk, and intense coding discussions on the same page if it was going to be a firehose. People can handle the commingling if it's not a firehose; loads of our talk pages are mix of different kinds of discussion. — SMcCandlish☏¢ 😼 03:32, 1 July 2018 (UTC)
Yeah, splitting them made a lot more sense earlier on when the traffic volume was higher. If the combined page size won't be too prohibitive, I'm cool with merging them all back together. Although I'm thinking instead of an omnipage, we leave Tasks where it is, merge Policy and Admin, merge Technical and Design, and move General to Main, per SMcCandlish. The corresponding archives would be moved/merged as well. The final talk page locations should probably also line up with a project page, to reduce the redirect soup. — AfroThundr (u · t · c)21:20, 30 June 2018 (UTC)
Support Nom - I understand The Transhumanist's comment, but going for an 'omnipage' may cause this talk page not as easy to navigate. I, however, now think that the use of 5 subpages is a bit unnecessary. Wpgbrowntalk | contribs21:25, 30 June 2018 (UTC)
Not fussy Fewer pages would help to find things, so support the idea in principle. Not bothered whether it is to 1, 2, or 3. Can be consolidated further later if needed, though may be less work to do it once. · · · Peter (Southwood)(talk): 06:58, 1 July 2018 (UTC)
Support three-page version, this is very similar to what I suggested when the split was initially proposed. - Evad37[talk]10:18, 3 July 2018 (UTC)
I'm not fussy either, but it does strike me as ironic that we've been striving to reduce the number of portal subpages while creating multiple project talk subpages. WaggersTALK15:31, 3 July 2018 (UTC)
Beat me to it. I still think Wikipedia:WikiProject Portals/Design should point to something though. Tasks has a corresponding project page, and so should Design. Perhaps the Components page would match well with the Design talk page? They kind of complement each other - one demonstrates the layout and template usage of a modern portal, and the other discusses all of those details. Is it even possible to join a page and a different talk page together and preserve history? I'm guessing we'd at least have to delete the redirects. — AfroThundr (u · t · c)19:34, 5 July 2018 (UTC)
Note: I've hacked together what I mean by retargeting the relevant redirects. Design and Components are now "linked". Now if we could get the page moved properly... — AfroThundr (u · t · c)19:41, 5 July 2018 (UTC)
Resurrecting the featured portal process
Is anyone interested in this? It was a major driver for portal improvement when it was active, and hits on former featured portals went through the floor when it was retired, which was extremely discouraging for maintainers. Espresso Addict (talk) 01:28, 5 July 2018 (UTC)
I believe we were waiting on resurrecting the FP process for now. We wanted to finish the portal maintenance overhaul and get our regular assessment process fully running first before considering bring back that process (and the significant administrative overhead that goes with it). I'm not opposed to restarting it eventually, but for now it would probably be premature. — AfroThundr (u · t · c)02:59, 5 July 2018 (UTC)
Thanks for the quick reply. That does make sense. I'd be willing to help out with administering the featured process. I did a fair amount of reviewing when it was active, and was engaged with Sven Manguard in sweeping all the featured portals when he retired. (The majority of the older ones needed demotion if identified issues were not fixed, as I recall.) It would be helpful if the admin burden could be more automated; as I recall, this was one of the reasons behind the process's failure. Espresso Addict (talk) 03:17, 5 July 2018 (UTC)
Not much point in getting it going until the general quality requirements and guidance are stable, and those may vary as the available tools change. However, this is no reason not to discuss changes and how they would affect FP criteria and assessments, including how automated content provision should affect FP criteria. Hint: it must be possible to reach FP in a fully automated portal system, or the whole point of the current work is degraded. If we are to allow both manual and automated portals, both types must be able to reach FP under the same rules, and both types must remain compliant with those criteria to remain featured. By all means work towards what appears to be reasonable criteria for FP, for both types, and upgrade axamples to those levels, and ask for cpinions, as that will help us work out what can work and what can't. · · · Peter (Southwood)(talk): 06:31, 5 July 2018 (UTC)
I find it hard to see how what the project is now calling automated content (NB in talking to oldbies, be aware it is highly ambiguous as it was formerly used to indicate that the portals had rotating content without needing manual monthly updates) could become featured against the old standards, unless all text content included was featured (because featured leads are relatively stable and all have similar lengths). It's certainly an area for debate... We used to talk a lot about the balance between article quality and article relevance to topic, as well as issues of topic balance/interest; I've always thought more variety and relevancy is best, but there was a large school that considered article quality was the most important/only indicator.
My former featured portal is Portal:Cheshire. I've been working on and off since 2013 on Portal:Viruses, which I had hoped eventually to bring to featured status. (A herculean task in this case!) Neither is suitable for automation in the way this term is now being used, though I am wondering whether data such as population@date, or infections@year, or death date (for someone now living) could be somehow pulled from Wikidata. Espresso Addict (talk) 07:03, 5 July 2018 (UTC)
That is why we need amended criteria. Many of us working here to upgrade the system and get most portals automatically updating by the new standards are unlikely to be interested in a system which prevents the maintenance free portals from ever becoming featured, so a review using the existing criteria might end up with few reviewers and little support. A portal which does not provide a route to lead the reader to the majority of the articles in its topic is failing in an important function, that of topic navigation. A portal on a very broad topic should not be unduly handicapped by an inconvenient fact like there may still be thousands of potential articles which do not yet exist, or that new articles are added on a daily basis. Featured portal quality should indicate the portals which work best for the reader, and showcase well-formatted, high quality and broadly representative content. Also, portals are introductions to the mainspace articles in the topic, they are not a content fork, so any information drawn from Wikidata must be in the original article, with adequate citation if relevant. Viruses may be one of the topics where this is practicable. I would like to see how it can be done. · · · Peter (Southwood)(talk): 09:46, 5 July 2018 (UTC)
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:
A portal that is under construction, severely underdeveloped, or otherwise does not serve its purpose as a portal. Readers would be better off viewing the topic's main article.
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:
content can be accessed on screens of any size, including mobile devices
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. WaggersTALK11: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 Transhumanist20: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. WaggersTALK20: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 Transhumanist22: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 --Ｔｏｍ (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:
(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
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.
Up to date. Significant changes to article content are reflected in the portal content, either via transclusion or other automated means or manual editing.
A portal that is under construction, severely underdeveloped, or otherwise does not serve its purpose as a portal. Readers would be better off viewing the topic's main article.
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 thesechanges. 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 (talk ⋅ contribs) 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 (talk ⋅ contribs) 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:
[ec]
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)
(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.
Up to date. Changes to article content are reflected in the portal content, via transclusion or other automated means.
A portal that is abandoned, severely underdeveloped, or otherwise does not serve its purpose as a portal. Readers would be better off viewing the topic's main article.
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)
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)
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.
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
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.
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.
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.
A portal that is under construction, severely underdeveloped, or otherwise does not serve its purpose as a portal. Readers would be better off viewing the topic's main article.
@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:
A portal that is under construction, severely underdeveloped, or otherwise does not serve its purpose as a portal. Readers would be better off viewing the topic's main article. Editors are encouraged to further develop these portals, but abandoned start-class portals are at risk of being speedily deleted.
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.
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)
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)
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)
Portal has significant room for improvement; it meets the Wikipedia:Portal guidelines, but fails several of the portal quality criteria, or fails any by a large margin. It is is useful enough for Portalspace. This is the minimum requirement to be left unaltered.
A portal that does not meet the Wikipedia:Portal guidelines, so is not yet a portal. It does not belong in portal-space, and should be draft-spaced or userfied if not fixed within a specified period (1 month?). If an attempt at a portal has no clear chance of meeting the portal guidelines based on the available articles it should be deleted until the topic has developed sufficiently
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)
I agree as well. These names would certainly work. They're distinguished from article names as many requested, but there's also no use of "Broken" or other names that many editors found concerning. They're based off of how complete it is, but they don't use unusual names like "Sufficient." I support this proposal. Brendon the Wizard✉️✨17:40, 28 July 2018 (UTC)
"Featured portal" should be removed until a featured portal program is actually in place again. Instead of "incomplete" or "underdeveloped", "under construction" captures the essence of a portal that was started and then abandoned, or that is still actively being constructed. It would also tie in nicely with the existing "under construction" category, which would be efficient use of tags.
I don't like the idea of drafting portals in draft space, especially multi-paged ones. That implies we should move existing starts (with all their subpages) to draft space, and that could get messy, and would create many superfluous redirects. It also breaks the portal creation template. The wikicode in Template:Box portal skeleton relies heavily on the magic word {{PAGENAME}}, which doesn't work right when the page is named Draft:Portal:Whatever.
We have an opportunity to push the envelope. How about Featured, Robust, Complete, Substantial, Basic, Under construction, and Meta-portal. "Robust" would be a portal that goes above and beyond. A bit of arm waving to catch the attention of other portal editors. Sort of like, "hey guys, take a look at this one!" A portal essentially ready for Featured, without having gone through the featured approval process yet.
I'm concerned that "Complete", "Robust", and "Featured" would require or imply that all the available section types are included in the portal. There is only limited subject support for "In the news" and "Did you know", for example, with only a few hundred portals likely to get populated with entries for those, hedging out most subjects from those ratings, especially when the numbers of portals grow into the thousands.
Another possibility is to redefine "Featured" for portals, by making it the top rating, without having a formal featured approval department or process. Or get rid of it completely, and use an informal word instead (like "Robust", or something else, like "Excellent"). Or keep it semi-casual, and only require a discussion on the portal's talk page, rather than at a centralized location. "Featured" implies a bid for presentation on the Main Page, but I'm just not sure portals are appropriate for that. But, if we do have a "Featured" status, I would like it to be achievable by all portals, and not bottlenecked by a queue. For example, if the handful of people at the Featured Portal department only have the capacity to approve 100 portals per year, then it would take 15 years to approve all the portals we currently have, and 100 years if portals numbered 10,000. That is not scalable, and would create an arbitrary elite class of portals.
Aside from the ratings, to make things more fun, maybe we could have some tags that don't fit within that scale, but that go in the same box, like "Innovative". This would attract editors to portals that apply new or experimental features.
It's not my area of expertise but that all looks good to me: well done! We should probably use "Featured" only if a portal did feature somewhere. If there's no relevant showcase then "Excellent" or a synonym would be more appropriate. Certes (talk) 22:10, 28 July 2018 (UTC)
I only took a quick glance at some of the discussion. For now, my opinion is that if we're restoring featured portals, it should go back to the featured star (to be consistent with other featured items (articles, lists, pictures and topics), not the hollowed out star currently presented. If I remember correctly, the hollowed star was to signify those portals which were featured at the time the featured portal process was stopped. OhanaUnitedTalk page05:13, 29 July 2018 (UTC)
Generally like it, and prefer: Featured, Complete, Substantial, Basic, Under construction (per The Transhumanist), and Meta-portal. However, "Under construction", like "Under[-]developed", is a bit long, so "Incomplete" is also fine. Avoid "Start", which is an article class. "FPo" doesn't mean anything to anyone; use plain English. Use consistent Featured star, per OhanaUnited.
I don't have a strenuous objection to introduction of Robust as a portal equivalent of A class, but it's iffy. The A class is actually very disused and could probably be eliminated, like I managed to recently get rid of B+ class (for A, run them through GA if not already a GA, or through FA, and reduce the non-GA ones to B class by default and in the interim. There are even objections to A class continuing to exist because it's not subjected to any process other than a single wikiproject's "local consensus" yet is put above GA.) If we added Robust, it would imply and probably necessitate an assessment process that we don't have. Better to re-establish Featured Portal, then see if, later, we actually need a Robust/A class, about which I'll remain skeptical.
I'm opposed to introduction of even more subjective "side" ratings like "Innovative"; it's just orthogonal to the purpose of this scale. Maybe create some other kind of award/barnstar/whatever.
We can have Featured right now, since some portals did receive it under the original assessment process and were not stripped of it by any process that deemed they'd fallen out of the requirements for it as established at the time. We just need a new process for issuing that assessment against. — SMcCandlish☏¢ 😼 06:48, 29 July 2018 (UTC)
The proposed rating scale is not the old rating scale. Old ratings no longer apply. Any portal that is nominated for Featured will have to comply with the featured portal criteria of the current system, which have not been decided yet. The hollow star indicates that they were rated af FPo on the old system, not that they are necessarily FPo on the new system. The solid star would be awarded after a FPo review, after we have agreed on the criteria. Depending on what the new criteria turn out to be, all, some, or none of the previously featured portals may make FPo. If some people want to jump through the FPo hoops, for a few portals, that is OK as it sets a standard for portals which are agreed to be really good. I don't see a need for a majority of portals to be rated as featured. That is a lot of work and time, which I would rather spend on more productive work, but that does not eliminate the value of the occasional review for FPo as an exercise in setting the bar for our best work. I see featured portals more as a set of good examples for comparison than a goal for all portals. Maybe Exemplary would be a better term than Featured. Completeness is a more useful target, and robustness is in my opinion, an independent charcteristic, allowing for complete but fragile portals, where the fragility is a function of their need for continuous maintenance to remain complete, whereas a robust portal will hold its level of completeness with less or no human intervention. Whether robustness is actually worth specifying as a classification is open to question. What purpose would it serve? Either a portal holds up over time, or it doesnt, and needs to be fixed. With any luck it will be fixed to a more robust version. The robust will survive, the fragile may be kept going by maintainers. It makes little difference to the reader.
If a previously featured portal is substantially changed, should it retain the hollow star, or should it get the broken star as is customary for other featured material, or both?
Tags like Innovative would be useful, but I don't think as part of the basic rating scale. They would be additional commentary, to direct portal aficionados to portals where they may learn something to improve other portals. I suggest such additional tags should accompany an explanation of what is innovative, as they may become mainstream over time. · · · Peter (Southwood)(talk): 07:28, 29 July 2018 (UTC)
I was thinking of robust in the context of having lots of features, to be a useful (strong) browsing tool. But perserverance works too. I like "Exemplary" even better. — The Transhumanist07:15, 31 July 2018 (UTC)
Support this rating scale - it's important to have some sort of rating scale for this project given there are so many portals and this seems to be quite reasonable. Any small issues can be ironed out as it's deployed - better to have something that's pretty good rather than nothing, I suggest. --Tom (LT) (talk) 23:17, 15 August 2018 (UTC)
I assessed Portal:Precambrian, a portal which is important enough, but it is in its infancy; "basic" or "start". The quality assessment however doesn't show and also it is not categorized, so how do we keep track of this? @The Transhumanist: any suggestions? Tisquesusa (talk) 20:42, 17 August 2018 (UTC)
@Tisquesusa: the rating won't appear because they haven't been implemented in the project banner template yet. Once we have consensus on the class ratings, the new classes will be added, and your changes will show correctly. As a side note, you may want to tweak the box-headers to use a more accessible color scheme. — AfroThundr (u · t · c)23:52, 17 August 2018 (UTC)
@Tisquesusa: My advice is not to worry about ratings, but to dive into portal development itself. That's where all the fun is. My specific advice for this portal is:
Convert it to a one-page portal, so the sections can be populated just by specifying sourcepage names or excerpt page names. Done
Use an image slideshow, and fill it with images (by naming sourcepages) Done
Migrate the related portals content from the subpage Done
Migrate the topics section content from the subpage, and reformat to h3 headings so that they can be accessed by the transclusion templates used in portals other sections. Thus, the subsections of the topics section become the lists to populate your various "Selected" excerpt sections. Done
(The above tasks took me a little over a half an hour).
Refine the search terms (in the Did you know? and In the news sections - note that these sections only show up when there are items for them to display.) Done That gave us a few hits in the Did you know? section
Complete the topics section
Add "Selected sections" to correspond to each subsection of the topics section
Add more sourcepages to the image slideshow (to build the image collection displayed)
Yes, I agree, and I don't "worry" about it anyways. What I have been working on for the past months continues; linking the portals where I can and then it is easy to include information on the portals itself using the "What links here" option. I agree, those portals of the specific geologic eras need reworking, but right now I focus on the article space maintenance, which is a huge task in itself, and then I start working on those portals. The "Prehistory of..." portals have been useful as quite some articles were already created since I populated the "things to do" sections @The Transhumanist:. Cheers, Tisquesusa (talk) 23:10, 21 August 2018 (UTC)
I hadn't thought of using the What links here option for link gathering. It's cool how different people find various approaches to improve the project. Keep up the good work. — The Transhumanist23:19, 21 August 2018 (UTC)
@The Transhumanist: In the meantime, we should probably get around to implementing the rating scale. Minus restarting the Featured class (the consensus seems to be keep historical for now), everything else seems to be set. I don't think we'll get any more significant input for this discussion until the new system has been put to the test. — AfroThundr (u · t · c)01:16, 22 August 2018 (UTC)
Alright people, I think this discussion has pretty much run its course. Below is what we've come up with, after taking the latest feedback into account:
Portal has significant room for improvement; it meets the Wikipedia:Portal guidelines, but fails several of the portal quality criteria, or fails any by a large margin. It is is useful enough for Portalspace. This is the minimum requirement to be left unaltered.
A portal that does not meet the Wikipedia:Portal guidelines, so is not yet a portal. It does not belong in portal-space, and should be draft-spaced or userfied if not fixed within a specified period (1 month?). If an attempt at a portal has no clear chance of meeting the portal guidelines based on the available articles it should be deleted until the topic has developed sufficiently
If there are no further objections or concerns, this version will be implemented on our assessment page and in the project bannersoon-ish. Keep in mind the scale is not set in stone, this being a wiki and all. I think we need to try it live at this point before anything else can be gained here. — AfroThundr (u · t · c)03:44, 24 August 2018 (UTC)
@The Transhumanist: New criteria are now live, thanks to Evad37 for getting the custom classes working in the portal banner. Now we get to add grading portals to our mountain of tasks. — AfroThundr (u · t · c)05:09, 27 August 2018 (UTC)
