User talk:Pbsouthwood/Archive 11

This is an archive of past discussions about User:Pbsouthwood. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 5

←

Archive 9

→

Portals WikiProject update #017, 22 Aug 2018

This issue is about portal creation...

Creating new portals

Myself and others have been testing and experimenting with the new components in upgrading existing portals and in building new portals. They have now been applied in hundreds of portals.

The templates are ready for general use for portal creation.

They are still a bit buggy, but the only way we are going to work the rest of the bugs out is by using them and reporting the bugs as we come across them.

I look forward to seeing what new portals you create!

Be sure to report bugs at WT:WPPORTD.

The main portal creation template is {{box portal skeleton}}.

Portal creation tips

After starting a portal using {{box portal skeleton}}...

Placing a panorama (banner picture) at the top of the intro section is a nice touch, and really makes a portal look good. {{box portal skeleton}} doesn't automatically insert panoramas. So, you will need to do that by hand. They can be found at Commons:. For some examples, check out Portal:Sharks, Portal:Cheese, and Portal:Florence
The search term provided in the Did you know? and In the news sections is very basic and rarely matches anything. It is best to replace that term with multiple search arguments, if possible (separate each argument with a pipe character). For example, in Portal:Capital punishment, see https://en.wikipedia.org/w/index.php?title=Portal:Capital_punishment&diff=855255361&oldid=855137403 Searches in templates use Lua search notation.
Check the In the news and Did you know? sections for mismatches. That is, sometimes entries come up that shouldn't be displayed. If there are any, refine the search strings further, so they don't return such results.
Finish each portal you've created before creating a new one. We don't want unfinished portals sitting around.

Need a laugh?

Check out the Did you know? section on Portal:Determinism. — The Transhumanist 02:23, 22 August 2018 (UTC)

Please comment on Wikipedia talk:Interface administrators

The feedback request service is asking for participation in this request for comment on Wikipedia talk:Interface administrators. Legobot (talk) 04:31, 22 August 2018 (UTC)

the way I see it

your recent edits means you make https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Seamounts live again - I reckon you should rip the inactive tag out of its entrails JarrahTree 15:57, 23 August 2018 (UTC)

and never ask me what I think about https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Oceans - I think it should have task forces for the main oceans - simply to standardise info between the oceans - but hey - I have a personal dislike for those who enjoy tagging projects dead or inert or whatever - I enjoy resurrecting shaky ones back into life JarrahTree 16:05, 23 August 2018 (UTC)

Hi JarrahTree, I don't think my edits are that significant to the project. I am busy systematically adding short descriptions to oceanography articles as part of building an annotated outline list for the field, which will be used for a portal or set of portals on Oceanography, as part of a personal project to provide portals for marine science in particular and earth sciences in general, thus furthering a whole group of interests at the same time. I am always happy to assist in any project that coincides with my current activity, which wanders around a bit at whim, as there is just so much to do, and so much of interest. Projects are active or inactive as and when people work on them or not. My own opinion is that if you post on a project talk page and someone answers, the project is active, otherwise not, and it does not actually matter, as it can change from day to day, and people can work on articles within the scope of a project without paying any attention to the project itself. I like collaborative work, but also can get on with a solo project. Cheers, · · · Peter (Southwood) ^(talk): 17:08, 23 August 2018 (UTC)

I hear your cautious response - and thanks for your consideration to do so - I am perhaps a little more anarchic in response to the tagging and determinations - I understand where you are coming from on this, and appreciate that, and the processes that arrive at that position - perhaps I tend to a less formulaic caution - but in this case shall refrain from further action at this point (or goading towards action as well). Thanks for your time on this JarrahTree 23:29, 23 August 2018 (UTC)

No worries, I am also not impressed by unneccessary tagging that serves no useful purpose, but I consider some to be actually harmful, and thore are the ones I will actively resist, Cheers, · · · Peter (Southwood) ^(talk): 04:37, 24 August 2018 (UTC)

at least metrics/(aka the air that the wmf breathes) - will probably avert anything similar to the portal mess of some months back - but the old age inferno is interesting to watch from afar in relation to project wars... I hope you get the allusions JarrahTree 04:47, 24 August 2018 (UTC)

Not sure - probably not all of them. Are you suggesting that someone will propose deleting all projects, like they proposed deleting all portals? (and even closing down Simple English Wikipedia). I can't see that one getting very far. I don't even see a proposal for deleting projects labeled as "defunct" deleted getting very far. Someone will probably give it a try some time, and it will almost certainly fail, the question is how much time it will waste, and will it serve any useful purpose. Sometimes these things boomerang. Portals look like they may actually become something really useful, largely as a result of the efforts to get rid of them. This amuses me, as a supporter of even the old-style portals, and much more so the new style if they go where they look like they are heading. · · · Peter (Southwood) ^(talk): 05:11, 24 August 2018 (UTC)

Please comment on Wikipedia:Village pump (proposals)

The feedback request service is asking for participation in this request for comment on Wikipedia:Village pump (proposals). Legobot (talk) 04:33, 26 August 2018 (UTC)

Request for guidance

Hi. I created Draft:Religion in Togo few days ago using article wizard. But now I don't know whatelse to do to get article published on Wikipedia. No administrator has viewed it currently. What should I do next. Your help will be much appreciated. Regards Alina Haidar (talk) 12:43, 25 August 2018 (UTC)

Hi Alina Haidar, I see that your draft article is not substantially different from the section Togo#Religion, which is a redirect from Religion in Togo, the title your article would occupy if transferred to mainspace (published in Wikipedia as an article).

If you have sufficient information to expand the article enough to make it a stand-alone article, too big to merge with the section in Togo, then continue to develop your draft. If there is no great likelihood of this happening in the immediate future, expand the section Togo#Religion with your additional content. If it ever gets big enough, it can be split off to form Religion in Togo. Please improve the references to allow verification - <ref>CIA=Togo</ref> is not useful, though the others look OK.

When you think yout draft is ready for review, add the template {{subst:Submit}} at the bottom and it will be put into the queue. It is not ready yet. If submitted as is, it would be declined as containing substantially the same information as Togo#Religion.

My recommendation at this stage is to expand the existing section on religion in the Togo article, as this is easiest to do, and it can be expanded a lot before it will be too big.

If anything is still not clear, feel free to ask more specific questions, or you can go to the WP:Teahouse where new editors are welcome to ask about anything that may help them on Wikipedia. Cheers, · · · Peter (Southwood) ^(talk): 13:53, 25 August 2018 (UTC)

Thanks for advice. Regards Alina Haidar (talk) 07:54, 26 August 2018 (UTC)

You are welcome. Good luck and enjoy your work. · · · Peter (Southwood) ^(talk): 08:10, 26 August 2018 (UTC)

Please comment on Talk:Machine Intelligence Research Institute

The feedback request service is asking for participation in this request for comment on Talk:Machine Intelligence Research Institute. Legobot (talk) 04:30, 28 August 2018 (UTC)

Please comment on Wikipedia talk:Biographies of living persons

The feedback request service is asking for participation in this request for comment on Wikipedia talk:Biographies of living persons. Legobot (talk) 04:33, 30 August 2018 (UTC)

WikiProject X Newsletter • Issue 12

Newsletter • August 2018

This month: WikiProject X: The resumption

Work has resumed on WikiProject X and CollaborationKit, backed by a successfully funded Project Grant. For more information on the current status and planned work, please see this month's issue of the newsletter!

-— Isarra ༆ 22:24, 30 August 2018 (UTC)

One-minute portals

Peter,

Remember that discussion we had about quantum portals?

Well, we are getting closer.

As you know, I've been trying to shave time off of my creation of portals.

I've now got portal creation down to one to three minutes each.

I thought you might be interested in trying your hand at it. That way, we'd have 2 heads working out the kinks and finding better techniques, to make the process even faster, instead of just one.

The method definitely isn't ready to go mainstream, because there are too many ways for newbies to propagate problems.

And it is definitely not suitable for AWB, as it requires visual inspection (preview), which is better suited to tabbed methods.

Though it doesn't work for just any subject. Only for subjects that happen to have the right resources.

Fortunately, there are a lot of them.

[Edit note: We should probably keep it down to 25 to 50 per batch/session, for quality control purposes. (Note that WP:MASSCREATION applies to articles and categories, and not to portals).]

I was wondering if you would like to try the method.

I look forward to your response. — The Transhumanist 23:55, 29 August 2018 (UTC)

Hi The Transhumanist, I am interested, tell me more.

Specifically, link me to a few so I can get an idea of their quality, and fill me in on what the right resources are and your method of production, so I can try it out.

Cheers, · · · Peter (Southwood) ^(talk): 03:43, 30 August 2018 (UTC)

I created almost all of the portals in Category:Single-page portals using these or similar methods. Instructions to follow... — The Transhumanist 04:05, 30 August 2018 (UTC)

The two main elements are pictures on the root article, and a corresponding navbox template, but we do not prescreen, as that is what the visual inspection later is for.

Step one: search using WP:SearchSuite. With SearchSuite set to list (details off), sort, and wiki mode, do an advanced search of template space, using insource:navbox insource:whatever. The "whatever" is the search string you use to find candidate portal titles. Then you click on View 50 at the bottom of the page, and then change limit=50 to limit=5000 in the browser's url box. Press enter. That will give you a nice long bullet list of templates.

Step two: Turn off WikEd, and copy/paste the list into your sandbox. Then reactivate WikEd and use search/replace in WikEd to change "Template:" to "Portal:" You now have a list of portal links, with many or most of them redlinks.

Step three: Using Firefox, Ctrl+Click on a bunch of promising looking portal redlinks. But only click on correct portal names (unless you plan on restarting the tab with the correct portal name). That will create a new page for each, in edit mode, each in a new tab. If you use a different browser, you'll have to figure out the correlate for ctrl-click to do this. I usually click on 30 redlinks, to create 30 tabs, because after rejects (in the inspection step later), that produces around 25 good portals.

Step four: Ctrl+Tab ↹ to go to the first tab. Add {{subst:quick portal}}. Copy it, and Ctrl+Tab ↹ to the next tab. Then oscillate between Ctrl+V and Ctrl+Tab ↹ until all the tabs have {{subst:quick portal}} in them. Template:Quick portal is a slight modification of Template:box portal skeleton, with some specific adjustments and a new feature that Evad just completed for hiding navbox formatting in topic sections (we're testing it).

Step five: For each tab, press ⇧ Shift+Alt+P to get a preview of each new portal. Basically, oscillate between ⇧ Shift+Alt+P and Ctrl+Tab ↹ until all the tabs are in preview mode.

Step six: Inspect the new portal in each tab. Click on the image slideshow to make sure there is more than one picture in it. If not, close the tab (Ctrl+W. Look for Lua errors. The intro excerpt will be blank if there is an "&" or other strange character in the title. In that case, you can fix it by typing in the title in the place of the {{PAGENAME}} magic word (after you've saved the portal). But don't save yet. If the picture slideshow has a lua error, then it usually means no pictures on the root article. Close the tab. At this stage of development, we're looking for the low-hanging fruit. If you see any other lua errors or formatting errors, close the tab. If, on the other hand the portal looks good, save it, with the edit summary of "start portal". Complete this step for each tab, but don't close the new portals.

Step seven: Using Ctrl+Tab ↹ browse each new portal in the batch, to see if there is anything else you want to do to them. Like add a sourcepage or two to the image slideshow. This is when I add a panorama to region portals. You can sometimes find banner pics for into sections on other subjects as well.

Step eight: Cycle back through them and add the approriate categories. If you are doing all the same kind of portal (like musicians) in a batch, you can add that category to the creation template. But, if you plan to do that, it is best to make a copy of Template:Quick portal and use that, so others do not inadvertently get the wrong category on their portal creations.

That's the creation process. Each new portal will eventually need a talk page, and links to it from around the encyclopedia, but it is best to let new portals sit for awhile, to allow yourself time to think of ways to improve them, and to look them over again. I generally inspect 50 to 100 at a time (loading them into tabs) on return inspections.

If you have any questions, feel free to ask. Let me know what you think of the whole process. — The Transhumanist 05:53, 30 August 2018 (UTC)

Discussion

Navbox:

It appears that you are using the existence of a navbox as a proxy for what I shall call portal notability – the evidence that a topic is sufficiently notable and sufficiently developed to justify the existence of a portal on the topic. This seems a reasonable assumption as it is easy to see the number of linked relevant articles in the navbox, and make an educated assessment of whether it looks like enough, which is at this stage a subjective decision. (Check: do we have guidance on this yet?) At this stage there is no check for article quality (class) or importance to the root topic, though the fact that someone has taken the trouble to include it in the navbox suggests that someone considers it relevant to some degree, and that no-one who has noticed disagrees strongly – a reasonable proxy for Wikipedia style local consensus that there is some importance. I don't think this will scale to the general editing public yet. Some competence is required. Quality remains an issue – a portal should not consist entirely of stubs. Again this is not likely if there is a navbox, but it is not impossible. My personal opinion is that the root article should probably be around B-class or better to justify a portal, as B-class is not difficult to achieve, it just takes some effort (open to discussion on this one). Alternatively the root article should at least be of some intrinsic importance, like a level-X topic.· · · Peter (Southwood) ^(talk): 08:38, 30 August 2018 (UTC)

A navbox itself is not necessarily enough to justify a portal. Some navboxes only have 2 or 3 topics in them. I ran into one where all the topics were redlinks except for two. I skipped those. Notability is not an issue, as that pertains to the topic itself, not the breadth of the topic or its coverage on WP. We don't want to cause confusion with the notability policy. This portal design provides more than just a mere one-page sample of a subject. Its slideshows make it a browsing tool. So the question I ask myself before I use it to build a portal is, "Will this portal improve the user's access to the subject?" If the answer is "yes", I build it. There was a template with just a handful of topics in it, but, since they were broad articles, I went ahead and built the portal.

There is no guidance as to what the minimums are, as of yet, though there is one obvious default: a slideshow with one image in it is not a slideshow. For the < > controls to work, there must be a second image. So, the minimum for an image slideshow is 2 entries. I learned this be awkwardly creating a number of one-image "slideshows". We don't have to worry too much about a short slideshow, as there are often pictures in the excerpts as well to supplement them, and the image slideshow can be expanded upon in the future. Just like articles, there are portal stubs (in a sense).

A poor root article may not be enough to justify not having a portal. Since the quick portal template creates a complete portal almost instantly, you can look at a preview to see if the portal is worthy, based on how well its various parts combine to make a whole.

As for the level of a topic, I think it has more to do with breadth of the topic, that is, how many subtopics it has. That's what browsing tools are made to navigate: pages. Are there enough pages to make having a portal worthwhile? — The Transhumanist 11:53, 30 August 2018 (UTC)

Sure there are trivial navboxes, but the advantage of using them is that it does not take long to look as a navbox and say yes or no to a portal, as there is generally more potential content than in the navbox, and seldom if ever less.

Images are great when we have them, sometimes there are none available for a topic, but the topic can still be worth a portal, so images cannot be required.

I foresee complaints if the root article is poor quality. Less so if it is reasonably good. If the lead meets B-class criteria, it is defensible. A one liner less so.

Level of topic: Both breadth and importance matter. Either one may justify a portal, both is best.

My use of the term portal notability has little to do with topic notability, it is intended as a measure of whether the content on the topic is currently suitable for a portal. A better term would be preferable. · · · Peter (Southwood) ^(talk): 13:25, 30 August 2018 (UTC)

Creation time:

I am guessing that the creation times claimed are the average for a batch. Creating one at a time would be slower?· · · Peter (Southwood) ^(talk): 08:38, 30 August 2018 (UTC)

I forgot to mention above, that the search (embedded in the DYK and ITN sections) usually needs refinement. The best time to do that is right after the creation of the portal. Better search terms, and more of them, improve the hits for news items and did-you-know blurbs. Part of the visual inspection is to see if the DYK and ITN sections have any overshoot. That is, entries that match the search terms but are off-topic nonetheless. In portal:Apples, the search term "Apple" would return much about a company that shares that name, and so adjustment of search was needed. The search features are fully Lua-capable, and can have wildcards and such. You can also have multiple arguments of search strings. — The Transhumanist 11:53, 30 August 2018 (UTC)

What you say makes sense, but the details of how to implement it are outside my current skill set. This will apply to many users, so if you come up with a tool which is easy for me to use, it may be easy enough for most people to use. · · · Peter (Southwood) ^(talk): 13:29, 30 August 2018 (UTC)

Complexity:

This process is fairly complex. It would require following a checklist with some precision to avoid errors, and is not the sort of thing one would remember from one week to another unless done frequently. I assume that the procedure will be automated at some stage as a Wizard, which will be a stand-alone gadget or script that does not require manual opening and closing of various other scripts or gadgets. Most people will want to create one portal at a time, as and when they perceive a need for it. Mass creation should be left to people with a fairly solid idea of what they are doing. Mass fixing is probably more useful, though that would be a semi-automated step-through process. Maybe with the same tool, maybe not, but the fixing tool should be upgraded to keep pace with the production of new portals, so we don't end up with a huge number of new portals that are already out of date. The fixing tool should be as idiot resistant as reasonably practicable.· · · Peter (Southwood) ^(talk): 08:38, 30 August 2018 (UTC)

The process itself prompts the user, for the most part. All you really have to remember is to put {{subst:quick portal}} on a blank portal page, hit preview, and then inspect the page. If there's anything wrong with the page, you'll see it and can fix it.

I am working on an automated tool for portal creation, but so far it only works after you've already pulled up a blank new page, then it inserts the subst: code, and then it saves without letting you preview first. Not very useful yet. :) — The Transhumanist 12:05, 30 August 2018 (UTC)

Wikipedia was not built in a day, and it is largely built by people who really have no idea of the technical workings. Tools must be usable by those who understand the content enough to use them well, there may not be that much overlap with those who understand the workings. With good tools this does not matter much. Previews are important for people who don't really know what the code will do.· · · Peter (Southwood) ^(talk): 13:29, 30 August 2018 (UTC)

Haste vs speed:

In the long run, there is no deadline. It may be less work to create portals at a moderate pace until we are fairly sure where we are going with them, so we don't generate too much work to bring them all up to the latest standard. If you are satisfied that you can upgrade faster than we all create together, then no problem. · · · Peter (Southwood) ^(talk): 08:38, 30 August 2018 (UTC)

There is time pressure. Remember the RfC. The portals have to improve well enough before the next RfC in order to survive it. I see two approaches here: 1) improve the existing portals so that their complaints no longer apply, 2) create more new portals of the new design than there are portals of the older designs, making the problem portals a minority. Also, we can't go so slow that the other editors lose interest. That's why I post newsletters, tasks, etc. often.

As you have pointed out, it may be faster to create a new portal from scratch than upgrade an existing one. So, upgrading a portal later may be as simple as running the latest version of quick portal on it. But, that depends entirely upon how sophisticated that creation template and our other tools get. At the same time, AWB is no slouch. I just used it to upgrade the topic section in over 600 portals. Evad found a way to make navigation templates blend in with the style of each portal. Now, there's no reason to build topic lists instead of transcluding the relevant navbox. With AWB, upgrading the new (standardized) portals is a breeze. It's the old non-standard ones that are a bitch to process with AWB.

I think we should pump them out as fast as we can without violating any rules. That will give us a collection of new standard portals to work on, and will provide readers with the most benefit in the meantime. — The Transhumanist 12:05, 30 August 2018 (UTC)

Two issues here: Firstly I don't see the next RfC happening anytime soon unless a spate of crappy portals pours out of the project. In this case crappy is in the eyes of the beholder. A flood of trivial or unexciting portals might trigger some people to jump up and down, wail and gnash teeth, claiming that the end days are upon us. The new portals should be better than most of the old ones, so a net gain is obvious even to those who do not want to see it. Rerunning the creation system may well be the quickest method to upgrade, and if it does the job we have cracked the problem. The trick will be to minimise the manual tweaking.

Secondly, I agree that keeping on pace is important to maintain momentum. Our coding members have done awesome work so far. I hope they can keep it up long enough. I see my place as providing feedback and where possible, ideas, so I am experimenting with alternatives and extensions. One of the things I am looking at is the relationship between portals and sub-portals, and how to integrate them into a bigger picture that works intuitively for the reader. I envision a network of portals linking up and down like categories, so each portal can be both manageable and comprehensive, by using other portals to expand scope outside of the root topic. I hope to create an example/prototype based on Outline of oceanography in the reasonably near future, and may split Portal:Underwater diving if I can work out a logical way to do it. It is pushing the upper limits of manageability already. One of the options is to split out the people to Portal:Underwater divers.

I am undecided whether creating new portals or fixing old ones is more urgent. I think both must happen in parallel. If you are confident that updating the new style is that much easier than fixing the old style, maybe we should triage the old portals and select out the ones worth saving, and just rebuild the others from scratch. It looks like the selected image collections are the most valuable items in some of the old portals. Should we make an effort to salvage those first?· · · Peter (Southwood) ^(talk): 13:41, 30 August 2018 (UTC)

Quality:

Do we even have an agreed minimum standard for a basic portal yet? The guidance page only strongly recommends a few components on the assumption that there may be edge cases where some commonly used component is not possible. However I think there may be some essential components, and I think your experiments may have provided some useful experience to show what is possible in almost all cases. Do you think we should strengthen Strongly recommended · · · Peter (Southwood) ^(talk):

The defacto standard is Template:Box portal skeleton, and the growing set of portals based on it. I think the driving factor for most editors will be the creation templates, and the existing portals. Users generally create new portals in one of two ways: 1) By using a creation template like Template:box portal skeleton, or 2) by copying an existing portal and editing its wikicode into a new portal. Either way, they get all the features that are included in those. The instructions should be updated to reflect what Template:box portal skeleton provides. We should avoid requirements, to allow for innovation. Who knows in what direction future development might take? Besides, everything right now is fluid and in flux. I can hardly wait to see what Evad and Certes come up with next! — The Transhumanist 11:53, 30 August 2018 (UTC)

Evad and Certes are doing great work. So are several others. This is a team effort. However, we do need to keep track of where we are and where we are trying to go, so other people can work it out without too much difficulty. I would like to see more integration of a wider range of navigational aids, both in the portals and in ways of building portals. You have made good use of navboxes, I am looking at outline lists. In both cases there is scope to use structures that already exist, but in both cases they only exist for a limited range of topics, and for a limited scope within those ranges. I am finding that short descriptions are immensely useful in structuring outline lists, and should help get our somewhat chaotic category system to work better if we can get short descriptions to automatically display as annotation in lists and categories. Thus I also further the aims of another project. · · · Peter (Southwood) ^(talk): 13:29, 30 August 2018 (UTC)

Get a feel for it:

To really appreciate the nature of the enterprise, you should throw a few dozen portals together (not all at once). They only take a minute or two each, and so are convenient to do during the odd break here or there. Tinker with them, and you'll get a very good idea of what will be possible in the not too distant future. Considering how far we've come in such a short time, it is easy to imagine how much further we can take this technology.

The upcoming hurdle will be what to do when we run out of subjects that fit our current creation profile. But the main challenge remains the same: figure out how to harvest categories. That should blow things wide open.

The main assumption that I have concerning this project is that editor involvement will be minimal. That is, editor labor cannot be relied upon, and the project is not scalable based on editor participation. The only way this will work is with sufficient automation. With full or near full automation, reaching and maintaining 10,000 portals will be easy. I think we're about a forth of the way to the level of automation needed. — The Transhumanist 11:53, 30 August 2018 (UTC)

I will try to use your system for a moderate number of portals, but one at a time. I may use it for Oceanography, to see how the two systems compare. :Automation is the only game in town. Either we get it sorted at a satisfactory level or we burn out trying. Manual maintenance does not work in the long run. We have seen this. Manual construction can be good for investigating alternative arrangements, but no one lasts as a portal maintainer forever. Eventually almost all portals will be automated as their maintainers lose interest. They are just too much work for most people to keep up indefinitely by the manual route. Everything that can be automated must be automated eventually, and that is not just about portals.

10,000 portals would be averaging 500 articles per portal at our current numbers. I predict more. Cheers, · · · Peter (Southwood) ^(talk): 13:31, 30 August 2018 (UTC)

I was in the midst of automating outlines when the portals crisis hit, and will have to return to that eventually. Fortunately, some of our new tech will be applicable or adaptable to those. It also looks like we could benefit from automating the construction of navigation templates, as those currently provide portal content. Automating nav boxes will need automated category harvesting for sure. Other things that could be automated are Outlines, Indexes, and Category pages (not the categories themselves, though auto tagging of articles with categories would be a major innovation, but smacks of AI).

Note that WP:MASSCREATION applies to articles and categories, and not to portals, but we need to make sure we have good quality control in place throughout, so as not to create a problem. Applying inspection during the creation process, and keeping creation down to batches of between 25 to 50, should help with that. — The Transhumanist 22:58, 30 August 2018 (UTC)

Categories, outlines, indexes, portals, navboxes are all part of the system for finding content, so should be more amenable to automation. Categorisation seems to be the point where improvement is most needed, as categories provide structural input for the others. It may also be the place where professional input would be most appropriate, because a lot of the current categorisation is far from optimal. With good categorisation the others would be much easier. A lot of the problems with categorisation are due to the category lists not being very meaningful to the reader - the actual topic is often not well defined by the title, so it is not clear from reading a category list whether all the articles belong there, and I am finding firstly that a lot of articles are poorly categorised, and secondly that short descriptions help to spot the errors, but are not listed in the categories. Who knows where it will all end?

The more the creation of portals is automated, the less it will matter to chop and change. With a fully automated system a portal only needs to exist when someone wants to read it, at which stage it should be fully up to date. Until then, quality control by editor inspection is essential. Cheers, · · · Peter (Southwood) ^(talk): 03:50, 31 August 2018 (UTC)

Please comment on Wikipedia talk:Interface administrators

The feedback request service is asking for participation in this request for comment on Wikipedia talk:Interface administrators. Legobot (talk) 04:34, 2 September 2018 (UTC)

Administrators' newsletter – September 2018

News and updates for administrators from the past month (August 2018).

Administrator changes

None

Asterion • Crisco 1492 • KF • Kudpung • Liz • Randykitty • Spartaz

Optimist on the run → Voice of Clam

Interface administrator changes

Amorymeltzer • Mr. Stradivarius • MusikAnimal • MSGJ • TheDJ • Xaosflux

Guideline and policy news

Following a "stop-gap" discussion, six users have temporarily been made interface administrators while discussion is ongoing for a more permanent process for assigning the permission. Interface administrators are now the only editors allowed to edit sitewide CSS and JavaScript pages, as well as CSS/JS pages in another user's userspace. Previously, all administrators had this ability. The right can be granted and revoked by bureaucrats.

Technical news

Because of a data centre test you will be able to read but not edit the wikis for up to an hour on 12 September and 10 October. This will start at 14:00 (UTC). You might lose edits if you try to save during this time. The time when you can't edit might be shorter than an hour.
Some abuse filter variables have changed. They are now easier to understand for non-experts. The old variables will still work but filter editors are encouraged to replace them with the new ones. You can find the list of changed variables on mediawiki.org. They have a note which says Deprecated. Use ... instead. An example is article_text which is now page_title.
Abuse filters can now use how old a page is. The variable is page_age.

Arbitration

The Arbitration Committee has resolved to perform a round of Checkuser and Oversight appointments. The usernames of all applicants will be shared with the Functionaries team, and they will be requested to assist in the vetting process. The deadline to submit an application is 23:59 UTC, 12 September, and the candidates that move forward will be published on-wiki for community comments on 18 September.

Sent by MediaWiki message delivery (talk) 23:23, 2 September 2018 (UTC)

Please comment on Wikipedia:Village pump (policy)

The feedback request service is asking for participation in this request for comment on Wikipedia:Village pump (policy). Legobot (talk) 04:29, 4 September 2018 (UTC)

Portals WikiProject update #018, 04 Sept 2018

Bug hunt!

As you know, portals are now supported by a number of new templates, which are in turn supported by some new Lua modules.

Those templates and modules are being put to the test, in the new portals that have been created since this WikiProject rebooted, plus a number of existing portals that have been revamped.

The new portals, and revamped ones, can be found at Category:Single-page portals.

Please browse the new portals at your leisure, and report any and all problems that you spot. Post bug and other portal problem reports at WT:WPPORTD. Please report bugs, quirks, awkward aspects, or anything weird or off that you notice. Compliments and suggestions are also welcome. :)

When you report a bug, please indicate the portal's name, the section that the problem appeared in, and the name of the article appearing (first) in the section with the problem. Most problems will likely be encountered in the Selected general articles" section, due to quirks in a displayed article's wikicode that the lua modules don't handle yet. Your help in spotting those is of utmost value. Thank you.

Don't delete portal subpages just yet

For portals that have been converted to the single-page design, we are not deleting their subpages at this time, because we are working on ways to harvest the data from those pages. For example, the Selected picture subpages include filenames and captions that would be valuable for the image slideshows. Please don't delete portal subpages, for now. They'll be slated for d-batch speedy deletion after harvesting. Thank you.

Development notes

We are currently testing a feature added to {{Transclude files as random slideshow}} that allows it to accept both sourcepages and filenames. Courtesy of Evad37. This will pave the way for harvesting files and their captions from portal subpages, for use in image slideshows.

We need your help

The bulk of the work is being done by a handful of editors. But we can't do it all. We need help with spotting bugs, refining the search parameters in new/revamped portals (in the "Did you know..." and "In the news" sections), adding images to slideshows for a broader selection (they default to showing the images on the root article page but are capable of showing so much more), adding panoramic pictures at the top of the intro section of region portals (cities, counties, states, provinces, countries, continents, and other regions), to name but a few task types.

It is rewarding to be a part of the growing portal phenomenon. And you get to see its expansion and refinement up close.

Feel free to join in on the fun. ;)

Thank you, — The Transhumanist 06:56, 4 September 2018 (UTC)

Please comment on Wikipedia talk:Blocking policy

The feedback request service is asking for participation in this request for comment on Wikipedia talk:Blocking policy. Legobot (talk) 04:30, 6 September 2018 (UTC)

Please comment on Wikipedia talk:Interface administrators

The feedback request service is asking for participation in this request for comment on Wikipedia talk:Interface administrators. Legobot (talk) 04:33, 8 September 2018 (UTC)

Let's talk shop...

Dear Peter,

I'm going brain dead (figure of speech), and I want to get my thoughts down about portals and where they are heading, but I feel somewhat like a zombie after that AWB run. It helps me think if I'm actually communicating with someone. I hope you don't mind if I use you as a sounding board for the latest developments concerning portals...

There are 5 major types of activities in the Portals Project, that I can think of:

Writing software tools and components
Creating new portals
Converting old portals to the new design (using AWB)
Developing and maintaining portals (adding new features as they are developed, adding pictures to slideshows, adding panoramas or banner pics to intros, etc.)
WikiProject administration (keeping the task list up-to-date, keeping discussions alive, posting newsletters, etc.)

Though it feels like something is missing. — The Transhumanist 07:57, 5 September 2018 (UTC)

Hi The Transhumanist, More suggestions:

Assessing old portals and assigning quality classes, importance etc.
Some people will want to reinstate FPo. We will need to keep track of that and make sure it does not push things in an untenable direction.
Assess whether the state of the art is achieving the aims of the project (feedback).
The state of the art relies heavily on navboxes. It assumes that navboxes are reasonably up to date and correct, which is a large assumption and not very likely to be correct, based on comparison with categories, so we need a way to improve navboxes so the portals can automatically improve.
Logically, categories would be a very good basis for portal structure, but there are technical problems. Maybe a bot could collect and sort categories and create useful lists. Some big problems with categories are:
1. They are a mess. Overcategorisation is rife. Miscategorisation is common. Category lists give insufficient information on the topic of an article tojudge from the category list whether an article belongs or not. Short descriptions help a lot with this from recent personal experience.
2. Lua can't get lists from categories (I am told). I don't know why not, but assume this is true. This is a problem for real-time, but bot generated lists can be updated often enough for it to be a minor problem over a longer timeframe. A weekly or monthly run would be often enough to be pretty up-to-date for most topics, and seldom enough to watchlist some and occasionally take a look oneself. I would probably be willing to watchlist up to a hundred lists for occasional quality control.

More later, perhaps. I am brainstorming this a bit. Hope your moribund cerebrum doesn't take too much strain;-/ · · · Peter (Southwood) ^(talk): 09:11, 5 September 2018 (UTC)

On old portals, wouldn't it be faster to just work on them? The portals that need work come up automatically for the chore being worked on in AWB. For example, if the current AWB task someone decides to work on is to process all the remaining intro sections that don't have transcluded excerpts yet, the first AWB pass is to make a list of all the portals and remove the ones that have that transclusion template on them, leaving all the portals that don't. If I remember right, there are about 70 of them, not including portals with dedicated maintainers.
FPo provides us with an opportunity to push the bar higher. If, for example, we redefined the criteria to include "custom features not typically found on other portals". That would push portal developers to innovate new features. We could then implement those features on the rest of the portals, wherever applicable. Once a portal is no longer special, it loses its FPo status, pushing its developers to innovate again. :) FPos, then, would be the portals to emulate, as long as they can be automated.
What are the aims of the project? Root articles are pretty clunky for navigation, and so, that has always been the essence of portals for me: to provide an alternative entry point for a subject's coverage on Wikipedia. What about for you? How do you make use of portals?
My assumption on navboxes are that they are the most easily harvestable navigation resource at this time, harvestable with the tools we have right now. Eventually, state-of-the-art will be automatic taxonomy construction, but that is a little beyond our reach at the moment. That technology would allow us to build all of the navigation systems automatically, by having the computer read the articles and build the nav pages from what it learned about the subjects (determining for itself what topics belong to what topics). It's a central research vector of the AI field. I can hardly wait. WP has a few AI geeks. Talking them into working on this for us would be a major coup.
Categories are an incredibly valuable resource, because they comprise the most extensive navigation system on Wikipedia. Because of that, it is an obvious choice from which to fill in the gaps of the other navigation systems. Though, at the same time, those other systems can also be used to fill in gaps in the category system. None of them fully overlap the others.

Another of the big problems with categories is that the structures of similar subjects, and the naming of their subcategories, are not standardized. Countries, for example. And cities. There are synonymous category names across subjects, etc.
Concerning Lua accessing categories, a request has been made on Fabricator. See Wikipedia talk:WikiProject Portals/Design#Bug collection. We need to push that, prompt it, and encourage the developers, to inspire them to make it happen. The squeaky wheel gets the grease. We need to make this wheel SQUEAK! Concerning bots, before we can program a bot to do it, we need to know how to program anything to do it. Once you've built the capability into a user script (as a semi-automatic tool), then the step to make it fully automatic (and a request for bot approval) becomes possible. WP:JWB has the capability to access categories (click "Setup", then "Generate", to get to the dialog box to specify what category you want to harvest the entries from). I've been studying the JWB sourcecode (written in JavaScript), and it is starting to look less like Greek. Eventually, I'll figure out how it pulls the entries from categories. Then all bets are off.

Do you feel like learning a programming language? May I suggest JavaScript? You would instantly have a study partner (me). — The Transhumanist 00:17, 6 September 2018 (UTC)

Writing software tools and components

Evad has pulled off another major advancement. The template {{Transclude list item excerpts as random slideshow}} now accepts both sourcepage and filename parameters, intermingled.

That's significant, because it paves the way for harvesting the images and captions stored on portal subpages. Some of the slideshows of the old portals are of very high quality. It would be a shame to let those go to waste.

It also makes it convenient for editors to add pics to slideshows.

Concerning PortalTool, I've decided to work my way feature-by-feature from the top of the portal page, and down the page. So, the first feature will be a tool to assist in the picking of panoramic pictures or banner pictures, and placing them at the top of the intro section. That will be followed by a feature to change the parameters of the intro excerpt. Then there will be one to add images and sourcepages to image slideshows. The next feature will be for changing the search parameters used in DYK & ITN sections. These should keep me busy for awhile.

I've been writing a script for portal creation, but I got stuck on two problems: the first is that I can't figure out how to get the script to preview a page rather than save. It just saves the page without letting you look at if first. The second problem is that the script won't run when a page is created by ctrl-clicking on a redlink, which creates a new page with empty edit box in a new tab. That would allow you to click on redlinks from a list, and have a new portal waiting in preview mode in a tab for each click. Fifty clicks = fifty new portals ready for inspection. That would be sweet, but like I said, I've been stuck. — The Transhumanist 07:57, 5 September 2018 (UTC)

Good for Evad! So are we going to shove the file names in as a long list of parameters? Have you done any yet to look at an example? This sounds like it will be a largely manual task, but as it is pretty much a once-off that should be doable. Do we have a list of portals with a useful set of images?

is there a way to section-edit a single page portal? That could make adding files a lot more user-friendly. (This may be part of your tool)

I don't use VE, so have no idea if it handles portals well or badly, do you know?

How does mediawiki get a page to preview from the source editor? Or from VE? Who would know? Not getting a preview is a bit of a problem for anyone, but particularly for inexperienced editors.

What actually happens when you click a redlink? There is no page to go to, so it does something else. I have no idea what, but something in there creates a new page when you save, so fundamentally different from saving an edit to a record that already exists. Maybe this will have to be done in two stages - first click to create a blank portal page with the title, second click to substitute the main structure template, third click to edit using the tool? You would still want to preview the tool output, of course. Here of course I have no idea what I am talking about, so take that into account. Brainstorming again. Cheers, · · · Peter (Southwood) ^(talk): 09:13, 5 September 2018 (UTC)

To harvest pictures and captions on subsubpages, theoretically, it could be done in 4 passes with AWB. But, only if {{Transclude files as random slideshow}} gets altered to accept captions without numbered parameters. I've explained this harvesting method at Wikipedia talk:WikiProject Portals/Design#We need captions without numbered parameters. Evad is a genius, so he may very well figure out a way to do this. — The Transhumanist 10:13, 5 September 2018 (UTC)

Previewing a page is done by pressing Alt+⇧ Shift+p or clicking on the "Preview" button at the bottom of the page. I do not know how to do this from within a script. — The Transhumanist 10:33, 5 September 2018 (UTC)

When you click on a redlink, Mediawiki creates the page in edit mode. Here, try clickin on this redlink: Portal:Hats. When you Ctrl+click a redlink in Firefox, it does the same thing, but in a new tab, without jumping to that tab. You are still in the tab you were in, and so you can continue clicking on redlinks there. — The Transhumanist 10:33, 5 September 2018 (UTC)

The method I use now for creating fifty new portals in preview mode in fifty new tabs is this: Ctrl+click on 50 redlinks. Then go to each new tab via Ctrl+Tab ↹ and paste (Ctrl+v) {{subst:quick portal}} into it. Then go to each new tab again, and press Alt+⇧ Shift+p to get the preview. Then you have 50 new outlines in preview mode ready to inspect and save. Imagine if a script could get you there. I want the script to look for the "Creating Portal:" in the page title in the HTML, and process the page (as just explained) when it finds it. So, I wrote the script initially with no menu item. It was supposed to work automatically when the page was created. Though I never tested it on straight clicking of a redlink, just Ctrl-clicking. I'm glad we talked this out. I didn't realize I missed that. I'm going to go test it on that right now! — The Transhumanist 10:33, 5 September 2018 (UTC)

It turns out that clicking a portal redlink while the script is activated (without a menu item) creates the portal page and inserts {{subst:quick portal}} into it.

If you Ctrl+click on the portal redlink instead, it creates a blank edit box. But, if you subsequently press ⇧ Shift+Alt+p, {{subst:quick portal}} shows up and it goes into preview mode, displaying that. This cuts a step out of the manual procedure, and takes care of one of the two problems.

If I could find the method for invoking preview mode, the other problem would probably be resolved, and the script would probably be done. — The Transhumanist 13:37, 5 September 2018 (UTC)

P.S.:

Fixed — The Transhumanist 07:50, 7 September 2018 (UTC)

Great. Glad you managed. · · · Peter (Southwood) ^(talk): 12:25, 7 September 2018 (UTC)

Creating new portals

In the past month, about 1000 portals have been created. That's about 10 years worth at the old rate of production.

One tricky part is finding decent templates to base new portals on. The list of templates is cluttered with esoteric fact lists, like Template:1988 Summer Olympics women's basketball game A6. Finding good root subject-based topics lists among them is tedious.

I'd like to find a way to automatically screen templates for candidates, but this seems problematic. — The Transhumanist 08:22, 5 September 2018 (UTC)

I am about 200 short descriptions and some list splitting away from a big experiment for a set of nested portals for Oceanography. It is a different approach to navboxes, and a lot more work when the outline list has to be created first, but I have found that navboxes can be very out of date, and categories can contain a lot the should not be in them. However, perfect is still the enemy of good enough. Wikipedia gets by on good enough most of the time, with the occasional splash of pretty damn good, which is useful as examples of where to aim for. We just experiment, and tolerate stuff with potential. Much as we would like to automate everything immediately, some things take longer. You may find that once you saturate on portals, a bit of time automating indexes and outlines, and possibly navbox expansion, though that may be limited by the size people are willing to tolerate at the bottom of a page, you may find things that relate back to portal improvements. Better category management would also be useful. I think that may be an area where WMF could legitimately spend some money on professional R&D. Cheers, · · · Peter (Southwood) ^(talk): 09:34, 5 September 2018 (UTC)

Holy shit! That makes you a serious outline builder. I've spent a great deal of time building tools that help serious outline builders make outlines easier. I was in the midst of developing them further when the portal crisis hit and pulled me away from them. If you are interested, and assuming you use the Vector skin, copy and paste the following script into your vector.js page. Then take the following tour: 1) Browse some books in the book namespace. 2) Browse some categories. 3) Browse some navigation templates. 4) Use AllPagesWithPrefix and enter a prefix 5) Use CatTree to view a category (on the special page only, not on portals, and use the "pages except files" mode).

Those will automatically be converted to wikisource outline format, for easy copying/pasting into outlines, except for CatTree - for that you need to use the ("CatTree" and "CT") menu items that appear on the sidebar menu. Try 'em. Once you expand the tree, you'll see the wiki-formatted links to copy/paste. ;)

/*
== ViewAsOutline-Book ==

*/

importScript("User:The Transhumanist/ViewAsOutline-Book.js");


/*
== ViewAsOutline-Category ==

*/

importScript("User:The Transhumanist/ViewAsOutline-Category.js");


/*
== ViewAsOutline-AllPagesWithPrefix ==

*/

importScript("User:The Transhumanist/ViewAsOutline-AllPagesWithPrefix.js");


/*
== ViewAsOutline-CategoryTree ==

*/

importScript("User:The Transhumanist/ViewAsOutline-CategoryTree.js");


/*
== ViewAsOutline-NavBox ==

*/

importScript("User:The Transhumanist/ViewAsOutline-Templates.js");

/*
== OutlineViewTOCToggler ==

*/

importScript("User:The Transhumanist/OutlineViewTOCToggler.js");

/*
== OutlineViewImageToggler ==

*/

importScript("User:The Transhumanist/OutlineViewImageToggler.js");

/*
== Redlink stripper ==

*/

importScript("User:The Transhumanist/RedlinksRemover.js");

//

The rest use menu items. To see what they do to outlines, go to their talk pages. — The Transhumanist 12:05, 5 September 2018 (UTC)

P.S.: I know the ViewAsOutline features need to be put on a switch. I'll do that as soon as time allows. All observations, ideas, questions, etc., are welcome. — The Transhumanist 12:11, 5 September 2018 (UTC)

Is that why all the navboxes display a huge column of links down the middle of the page now? · · · Peter (Southwood) ^(talk): 12:28, 7 September 2018 (UTC)

Some navigation templates (but not all) use "center" somewhere in them. I don't know how to adjust for that in the new view, yet. Though copying and pasting still seems to work fine for those.

When copying/pasting links, beware of piped links. I haven't dealt with those yet. — The Transhumanist 21:22, 9 September 2018 (UTC)

Converting old portals to the new design (using AWB)

Even with AWB, this would take a person many weeks to accomplish. About a week per section, 2 to 4 hours per day.

I was hoping to get others involved, using AWB, but hardly anyone responds. On the bright side, Robertgombos did a big run recently, and that helped a lot.

So, I've been doing the bulk of this. I've been producing so many edits on this project that I continue to climb on the WP:NOE list. I'm closing in on #90. :)

If we can get the harvesting of subpages problem solved (to work without numbered caption parameters), then we could just replace the portal base pages with single-page portals, and harvest the subpages after that.

With this approach, the "low hanging fruit" strategy could apply. (Find the portals with subjects that fit the current easy-to-create-portals-for profile, and batch-create them). — The Transhumanist 23:16, 5 September 2018 (UTC)

Please comment on Wikipedia:Reliable sources/Noticeboard

The feedback request service is asking for participation in this request for comment on Wikipedia:Reliable sources/Noticeboard. Legobot (talk) 04:29, 10 September 2018 (UTC)