Wikibooks:Reading room/Proposals/2021/April

for Wikibooks
Currently, the  permission, which is required to import contents from most wikis (other than the ones where importers can import), can only be assigned by stewards following a RfP. My proposal is to bundle  into sysops and importers (if possible), as they will allow trusted users to import content from StrategyWiki and other sources (relevant because we allowed video game strategy guides). What do you think? Leaderboard (discuss • contribs) 13:36, 20 March 2021 (UTC)


 * I think we should show a lot of caution. Looking at Importer it describes 🇨🇴. The danger is explained at m:Help:Import as 🇨🇴 So it is a fairly technical thing to do, as if usernames shared by different users between, say, StrategyWiki and Wikibooks, the XML file will have to be edited.
 * My feelings is that we should create a policy for importupload, which could be amended at Importers. What that policy contains could be decided later, by my personal feeling is that we should restrict it to administrators, and it should remain separate from admin rights; the user group already exists, but with no users, see import uploaders. -- Jules (Mrjulesd) 20:11, 20 March 2021 (UTC)
 * Just to note, that importupload isn't technically required if importing from StrategyWiki, as the CC-BY-SA copyright compliance doesn't require it; attribution can merely be a link to the page from which it is imported. -- Jules (Mrjulesd) 20:19, 20 March 2021 (UTC)
 * Your approach is also OK by me, as I can understand the hesitation of providing importupload to importers. That being said, while importupload isn't technically needed for StrategyWiki, it's still useful, and importupload also helps when importing from most other Wikimedia wikis (other than the whitelist). Leaderboard (discuss • contribs) 20:51, 20 March 2021 (UTC)
 * OK I'll look into it. I was giving my opinion on what should be done, but what we decide could different to that. Importing histories is definitely better than importing without histories, but if usernames are shared by different users between projects then that could cause problems, and you would have to be careful to avoid this. -- Jules (Mrjulesd) 21:02, 20 March 2021 (UTC)
 * I've created a draft proposal at Importers/sandbox. What do you think? -- Jules (Mrjulesd) 22:32, 21 March 2021 (UTC)
 * I think your proposal for importers is OK.
 * With regards to, I am not sure whether we need admins to request it separately (that is, why not include it in the admin toolkit?). Additionally, I am not sure that we need to restrict it to admins either - I can see legitimate use-cases for non-admins to hold   and I don't want to restrict them from holding the right if needed. Whether importupload should be assigned by admins or bureaucrats is up for debate - I am fine with either. Regardless, I feel that at least one local group should be able to assign this right - we shouldn't have to go to stewards like I had to. Leaderboard (discuss • contribs) 08:23, 22 March 2021 (UTC)
 * Agree it should be assigned locally. Assignment, and removal, should be by admins not crats as really this project is too small for crats - if we didn't have one, you'd probably find that the Stewards wouldn't create any even if the community requested it. Regarding the points above, the issue is really non-WMF Wikis. Using it to bring data in from a WMF project that isn't supported by  is fine, but once you start with other projects you can mess up the attribution and data mapping to a degree. Given this, it shouldn't be part of the standard importer permissions. It makes sense to include it by default to admins. QuiteUnusual (discuss • contribs) 09:10, 22 March 2021 (UTC)
 * Agree it should be assigned locally. Assignment, and removal, should be by admins not crats as really this project is too small for crats - if we didn't have one, you'd probably find that the Stewards wouldn't create any even if the community requested it. Regarding the points above, the issue is really non-WMF Wikis. Using it to bring data in from a WMF project that isn't supported by  is fine, but once you start with other projects you can mess up the attribution and data mapping to a degree. Given this, it shouldn't be part of the standard importer permissions. It makes sense to include it by default to admins. QuiteUnusual (discuss • contribs) 09:10, 22 March 2021 (UTC)

Thanks for your feedback. Well I think there is a couple of issues to address:

Firstly, I accept whatever the consensus is for assigning the importupload right. And that currently seems to be that only admins should have the right.

Secondly, there seems to be consensus here that admins should automatically be given the right as part of their toolkit. If that's the decision I'm fine with it. However, I would give caution with a couple of possible scenarios on how it might go wrong, which I would like some feedback on if possible.


 * 1) Scenario : Editor X (on StrategyWiki) and Editor Y (on Wikibooks) share the same username on their respective projects. Now an importupload from StrategyWiki is performed, but the usernames are not altered to reflect this. Unfortunately, Editor X has performed some offensive edits, but after it is imported it looks like Editor Y has performed these edits, and this is then discovered; but it is not realised that this is due to an importupload.
 * 2) Scenario : A corrupt Admin X (or another editor with access to their account) decides to get their own back on Editor Y by rewriting history. They perform an fake importupload, with Editor Y making an offensive edit. Again this comes to light, but again it is not realised that this is due to an importupload.

Now you could say that this is pretty unlikely; but at the same time it would have the potential to cause a furore. I think that's why I see importupload as a dangerous permission, that needs considerable care and integrity. So that's why I suggested a process akin to interface admin. Furthermore its not actually needed for CC-BY-SA compliance, a link is all you really need.

Anyway, what do you think? If you're not convinced then perhaps we could just add it to the admin toolkit.-- Jules (Mrjulesd) 19:49, 22 March 2021 (UTC)
 * I maybe wasn't clear. I think it is okay to assign the right to non-admins on request in principle but I also think that we need to be cautious and only assign it to highly trusted editors who fully understand the kind of issues you are discussing above, particularly the attribution point as this is more likely. That would mean a proper RFP along the lines of request admin with community consensus. If this approach is taken, I support making it a standard admin tool and allowing admins to assign the rights. If the preference is to only assign it on request to admins, then I suggest making this a crat responsibility as it doesn't make sense for admins to be able to assign themselves a right that isn't part of the toolkit. Personally I agree that it is probably unnecessary given that attribution can be done by a URL. QuiteUnusual (discuss • contribs) 22:13, 22 March 2021 (UTC)
 * While I agree that all this is not necessary from a theoretical perspective, I am personally still of the opinion that it is a useful right to have; after all, we don't technically need the importer permission either as a link would suffice.
 * Regarding the scenarios, it's possible but unlikely, and would form the trust we give to these users. After all, a steward going rogue can make a large amount of damage very quickly. One way to mitigate the risk would be to ask users performing importupload to not select the option to attribute edits to locally existing users.
 * In my personal opinion, I would stand by keeping importupload by default for admins, and perhaps (in light of concerns) assigning importupload to non-admins (by either admins or 'crats) with somewhat stricter rules (which could range from experience, and perhaps even enforce 2FA). Wikibooks does require more imports than the average Wikimedia site. However, all this will depend on the direction taken by the community. Leaderboard (discuss • contribs) 08:10, 23 March 2021 (UTC)
 * OK well I suggest that you amend Importers/sandbox to how you see fit, and present it to the community for approval. I will !vote and comment on whatever you come up with; if it appears to be reasonable I will support. -- Jules (Mrjulesd) 11:58, 23 March 2021 (UTC)
 * I've made some updates to that; what do you think? Leaderboard (discuss • contribs) 18:06, 23 March 2021 (UTC)
 * yes its looking fine. I added some details about having a "proper" RfP per comments by QuiteUnusual above, and a bit of c/e. -- Jules (Mrjulesd) 19:42, 23 March 2021 (UTC)

Proposal to update Card Catalog Office with Card Catalog Office/sandbox
I've been working on a new page for Card Catalog Office, which I have created at Card Catalog Office/sandbox. Its rather more detailed, and it combines elements of Wikibooks Stacks/Departments with that of the present page.

When visitors first visit the site, the most likely way they're going to search is by going to "browse" on the left sidebar. Hopefully this page will be more engaging and give a better sense of where to find content than the current page. Any views are most welcome. -- Jules (Mrjulesd) 11:08, 29 March 2021 (UTC)


 * Looks fine to me. Leaderboard (discuss • contribs) 12:39, 29 March 2021 (UTC)


 * Thanks . Another thing I was thinking of doing was to raise Shelf:Recreational activities to Department:Recreational activities. It seems to me that this is the most popular shelf in Department:Miscellaneous, so it makes sense to give it more prominence. I've been studying the Wikibooks Stacks a fair bit, and I think it is actually very easy. I think what you need to do is:


 * 1) Update Card Catalog Office.
 * 2) Create: "Department: Recreational activities" and "Category:Department:Recreational activities" with the relevant templates
 * 3) "Shelf:Recreational activities", "Shelf:Collecting", "Shelf:Games", "Shelf:Outdoor recreation", "Shelf:Physical fitness", "Shelf:Tourism", "Shelf:Arts and crafts":  migrate parent=Miscellaneous to parent=Recreational activities
 * 4) "Shelf:Athletic games", "Shelf:Board games", "Shelf:Card games", "Shelf:Electronic games", "Shelf:Game design" are already subshelves of Games, so wont need migration.
 * 5) Rebuild these shelves through purging.
 * Any thoughts? If it didn't work it would be easy to reverse. -- Jules (Mrjulesd) 16:32, 29 March 2021 (UTC)
 * Looks fine to me. Leaderboard (discuss • contribs) 10:24, 17 April 2021 (UTC)

Update on my work
I have made some changes that I would like to advertise:


 * I have created a new department, Department:Recreational activities, which was previously a shelf. This means that Shelf:Games is more visible.
 * I have updated Card Catalog Office and Wikibooks Stacks/Departments; they now use CSS flexbox, and should display ok on smartphones.
 * I have created Wikibooks Stacks/Adding books and Wikibooks Stacks/Detailed structure, which should help with understanding of Stacks.
 * I have updated Main Page with more departments, using CSS flexbox for smartphone rendering.
 * Miscellaneous changes here and there.

As a general point, I'm learning more about Wikibooks Stacks, although I don't fully understand it I'm getting more aware of how it can be manipulated. I think I might manipulate Stacks further, I am concerned about smartphone rendering on pages. I imagine many users are put off by this, as most users today use mobile devices to access websites.

Any comments are welcome. -- Jules (Mrjulesd) 23:06, 6 April 2021 (UTC)

Proposal for new Main Page
See Main Page/sandbox. I am proposing that this replace the present Main Page. Changes can be summarized as follows:


 * The page now use CSS flexbox (for the most part). This means that rendering should be improved, even for very low resolution smartphones. There are also a few cosmetic changes here and there.
 * The page includes "promoted shelves" (see below) in addition to featured content.

The basic idea behind promoted shelves is that they exemplify the most popular areas of Wikibooks. The promoted shelves are "top-level shelves" (just below departments), and have some of the popular books upon them. I've based them largely on Wikistats at https://stats.wikimedia.org/#/en.wikibooks.org/reading/top-viewed-articles, and an analysis of what shelves (from which books) should be most popular with readers.

They are therefore selected on the basis of popularity not quality. Now that is a departure from a featured items on the Main Page, but is done for the following reasons:


 * Featured books/Wikijunior books/recipes are retained, with promoted shelves as an addition.
 * The recent video game strategy guides acceptance hasn't gained a strong foothold yet. Perhaps this will give it a boost with the inclusion of Shelf:Games as a promoted shelf.
 * Shelves are the main organizational structure of Wikibooks, yet possibly remain mysterious and obtuse to the general readership.
 * I think at this stage of Wikibooks we need to do something radical to try to boost readership. Readership is quite down from previous years, see https://stats.wikimedia.org/#/en.wikibooks.org . For example, total page views are down -37.35% year over year. Without readers our active contributors will also fall, and the stats bear this out too. Perhaps it is a time to focus on what brings the readership here, and at the same time popularize our Stacks sorting mechanism of departments and shelves.

At the moment promoted shelves are fixed, but in the future there could be a rotational aspect, like featured content. Anyway, all views and comments on this are most welcome. -- Jules (Mrjulesd) 09:58, 17 April 2021 (UTC)


 * Looks fine to me. However, should the promoted shelves be categorised? Leaderboard (discuss • contribs) 10:23, 17 April 2021 (UTC)
 * Indeed that would be a logical step. If this gains acceptance then that should be done. -- Jules (Mrjulesd) 10:31, 17 April 2021 (UTC)


 * Support, current main page is too short. Enjoyer of World (discuss • contribs) 22:45, 19 April 2021 (UTC)