Wikibooks:Reading room/Proposals

From Wikibooks, open books for an open world
Jump to navigation Jump to search
Replacement filing cabinet.svgArchivesWikibooks Discussion Rooms
Discussions Assistance Requests
General | Proposals | Projects | Featured books General | Technical | Administrative Deletion | Undeletion | Import | Permissions

Welcome to the Proposals reading room. On this page, Wikibookians are free to talk about suggestions for improving Wikibooks.


Categorizing individual pages[edit]

The time has come (I recommend) to work out how we want to do this; we want to get it right. Afaik we've wanted a good way to categorize individual pages for years, and were bogged down by a category infrastructure that served its purpose but got in the way of doing more; now that we've finished a year and a half of overhauling the existing infrastructure so that we can move forward (see previous thread), we don't want to get stuck with individual-page handling that doesn't do what we want and would take another humongous effort to fix. As background, before explaining what I envision and what we need to decide, here's what we now have:

We have two main kinds of organizational pages:

  • Book categories. A book category contains the pages of a particular book. For a book with main page <title>, the book category is Category:Book:<title>.
  • Subject pages. A subject contains books (not individual pages of books). Subjects are arranged in a hierarchy; each subject has one or two parents, except the ancestor of all subjects, Subject:Books by subject, which has no parent. Subjects are sort of like sections of a library. (The facility that subjects replaced, historically, was called "bookshelves".) The main page of each book, <title>, uses a special template, {{subjects}}, to name subjects that the book should be filed in (usually only one or two subjects, though more are possible; template {{subjects}} is internally quite complicated, btw, but the point is to hide all that so it's very simple to use). For each subject page Subject:<name>, books that file themselves in that subject belong to Category:Subject:<name>.

So the major categories have a prefix, either Book: or Subject:. That's really handy for keeping track of what kind of category you're looking at. I propose we do the same for the new categories that classify individual pages, and use a template on each page to file it appropriately. We need to make at least a couple of choices, to do this.

  • Should these categories be for books and individual pages, or just for individual pages?
I favor both, so that each category corresponds to a topic, making it analogous to an article on Wikipedia, topic category on Wikinews, etc.; thus, these categories would be natural targets for incoming wikilinks from other sisters.
  • What should these categories be called: what prefix should be used, and what template name for filing?
We could use prefix "Topic:" and template name {{topics}}; there's a danger users could get confused between "subjects" and "topics", though. I had considered "Keyword:", but it's been suggested that is too syntactic whereas I think we're after a more semantic classification; or "Tag:" but apparently that would collide with other usage on the platform (indeed, there is already a standard template called {{tag}}). So I'm having trouble coming up with a really good name.

On the technical side, it may make sense to modify the subject-hierarchy facility so that books in a particular subject can be automatically classified in certain of these more-inclusive categories (whatever they're to be called). --Pi zero (discusscontribs) 21:02, 17 January 2018 (UTC)

First off, I definitely think that individual pages can be categorized on a by-page basis. Two examples immediately come to mind: let's say that you have a textbook on a broader topic that includes a page on a more narrow topic which itself also has a textbook (e.g. A page on Spanish morphology in a linguistics book but we also have a textbook[s] on Spanish). Another is categorizing pages by type, such as Category:Coding examples for all of the textbooks about computer programming which have individual pages which are just code or Category:Math worksheets, etc. I think there is definite value in these. To give an example of the how the latter is useful, imagine if MediaWiki changes how it renders code and there is a better way to make it visible or if someone builds a little tool for randomizing homework questions from a bank and we can deploy that tool across textbooks faster. As to your second question, I'm open to suggestions. Topic was what came to mind immediately but I agree that it seems too ill-defined compared to "Subject" (we had a similar issue with Topic/School/Portal on en.wv...) Plus, there is always the prospect that Flow/Liquid Threads will get deployed here and break a bunch of pages (as happened on en.wv). —Justin (koavf)TCM 09:28, 19 January 2018 (UTC)
I'd wondered about the variety of namespaces at wv.

The examples of per-page categories you mention are more technical classes of pages; we could do those, certainly, and perhaps we should, but I suspect they're yet a different type of category (more of an "internal" sort of thing). I've had in mind semantic per-page-or-book categories that would be natural sister-links to/from Wikipedia articles etc. They would share some of the advantages of en.wn topic categories. Two advantages in particular come to mind:

  • Sister links, incoming and (of course) outgoing: Each Wikinews topic category has outgoing wikilinks to Wikipedia (almost always), to Commons (usually), and sometimes to Wikiquote, Wikivoyage, etc.; and of course the category is also a suitable potential target for incoming sister links from those pages. When I set those up, though, I rarely provide an outgoing sister link to Wikibooks, because I can't easily choose one target here that corresponds to the Wikinews category.
  • In-project wikilinks: The more a project uses project-internal wikilinks, the more it feels like a coherent project (in the old days, almost all wikilinks in the body of a Wikinews article were to Wikipedia, and that made Wikinews feel more like an appendix of Wikipedia than like its own project, whereas with a "real" project like Wiktionary or whatever, readers in the mood to explore can spend an extended browsing session just clicking from one page to another within that project without ever being dumped into another such as Wikipedia unless they choose to); so the project needs to have as wide a range of targets as possible. We have a template {{w}} at en.wn that doesn't just link to Wikipedia: it first checks to see if the target exists in Wikinews mainspace, and if so it links locally, otherwise it links to Wikipedia; which over time has allowed the project to feel much more coherent.
I deplore Flow, which I see as an example of the Foundation trying to go in diametrically the opposite direction from what is best for the volunteers and sisterhood (other examples being VisualEditor and some aspects of the implementation of Wikidata). At en.wn we use liquid threads (LQT) — only for our "opinions" pages, where readers discuss the topic of an article; we all "love to hate" LQT, but agree that for that one purpose it actually works better than wiki markup which most readers don't know (more's the pity), and we'd far rather LQT than Flow even for that purpose. My hope is that, with a bit more experience in how to effectively use wikidialog, we can implement semi-automated tools to assist wiki-markup-based discussions, making both Flow and LQT irrelevant. --Pi zero (discusscontribs) 13:11, 19 January 2018 (UTC)
Visual editor isn't bad. It is useful for wikipedia, and perhaps only wikipedia.
Im thinking of categorization of the ones that are ok. Then others can be case-by-case. Some pages could be both marked.
Artix Kreiger (discusscontribs) 14:37, 19 January 2018 (UTC)
Of VisualEditor: I consider WYSIWYG to directly undermine the human foundation of wikis, because (I maintain) wikis are a successful thing thanks to wiki markup, and people learn wiki markup by seeing how other people's wiki markup is written, but WYSIWYG is all about preventing the user from seeing how things are done underneath. --Pi zero (discusscontribs) 14:55, 19 January 2018 (UTC)

Subjects and sections[edit]

  • One approach would be to rename the existing "subject" hierarchy to something else, and reuse the Subject: space for the purpose. It'd be a bother to do, but it could be done — it's a highly uniform mechanism and I understand it thoroughly — and once done it'd be done. There are nomenclature advantages for both kinds of pages:
  • The name "subjects" for the existing hierarchy has always been a bit odd; how about calling them "sections"? When explaining them I tend to say they're like sections of a library.
  • The non-hierarchical groupings of pages are organizationally much more like the physical dead-tree subject catalogs that were ubiquitous in public libraries prior to the twenty-first century. (The old dead-tree subject catalogs were superior, btw, to most of the electronic catalogs that have replaced them, because those old catalogs had been crafted by hand over time in a very wiki-like way; but I digress.)
--Pi zero (discusscontribs) 21:05, 3 February 2018 (UTC)
That seems like a reasonable scheme. —Justin (koavf)TCM 05:26, 4 February 2018 (UTC)
A snag occurs to me. Atm the standard template on a book main page to file it under subjects is called "subjects". If that gets renamed to "sections", the name may make people think of sections of the book. Perhaps a different name for the template... --Pi zero (discusscontribs) 12:05, 4 February 2018 (UTC)
Such as {{library}}... ---Pi zero (discusscontribs) 12:07, 4 February 2018 (UTC)
Brainstorming about terminology. This renaming can be done, but it's not a small operation, so once we commit to it we're likely to live with it for quite a while. In the old system, from before subjects, the root page was Wikibooks:Departments, and the subdivisions were called bookshelves. It does bother me some that "section" is so generic it can be used to refer to a part of a book. "Department" sounds to me like a top-level subdivision of the entire library. "Shelf" is good in that it has high recognition value as a grouping above the book level, but it sounds odd to have one "shelf" contained within another "shelf". We can't use "collection" because it's been preempted. --Pi zero (discusscontribs) 14:19, 5 February 2018 (UTC)
Also worthy of mention: stacks. --Pi zero (discusscontribs) 19:05, 5 February 2018 (UTC)
(Looked around a bit for a good picture of library stacks,
Library Stacks (8145376020).jpg
having spent many happy hours in such places.) --Pi zero (discusscontribs) 19:11, 5 February 2018 (UTC)

┌────────────────┘
I'm now leaning strongly toward prefix Shelf:, which seems likely to have instantly graspable meaning. Instant recognition of intended meaning seems to be the top priority for this. The oddity of one "shelf" being a subset of another is something one can just get used to. --Pi zero (discusscontribs) 19:42, 6 April 2018 (UTC)

Whether to reuse Subject: for the other purpose, or use some other prefix, is a decision we'd have time to consider, while the renaming of the existing hierarchy from subject to shelf was underway. --Pi zero (discusscontribs) 19:45, 6 April 2018 (UTC)
I agree if we merge them with Category:Wikibooks bookshelves. JackPotte (discusscontribs) 20:51, 6 April 2018 (UTC)
@JackPotte: Afaik, the organizational information in the old bookshelves is contained within the current subjects hierarchy. What do you have in mind when you say "merge"? --Pi zero (discusscontribs) 23:18, 6 April 2018 (UTC)
For example, to move Wikibooks:Greek bookshelf and Subject:Greek language, which have basically the same content, into Shelf:Greek language. In this particular case, there will be nothing but the history to get from the old bookshelf, but it may be worth comparing their contents, before closing this maintenance task, telling that the list is moving since 2009. JackPotte (discusscontribs) 04:20, 7 April 2018 (UTC)
Ah! Yes, I see. --Pi zero (discusscontribs) 12:56, 7 April 2018 (UTC)
I'm giving some thought now to details of page nomenclature. Presumably the categories — whose names are especially critical, as they need to be very lucid when they appear at the bottom of each book main page — would have names like Category:Shelf:Mathematics. However, there are at least three choices for the primary information page associated with that category (corresponding to the previous generation's Subject:Mathematics):
  • Shelf:Mathematics. This however is a root page in mainspace, with implications to think through carefully.
  • <bookname>/Mathematics, where <bookname> is the name of a book containing all the shelves; we might also want to have such a book even if its pages were to use prefix Shelf:.
  • Wikibooks:Shelf:Mathematics, which would exclude it from mainspace searches.
Some observations about these.
  • Because Shelf:Mathematics is in mainspace, it would be included in a general search of mainspace; that might be a good thing. One could do a search of pages with prefix Shelf: just as one would a search within a book. Because it is a root page in mainspace, it would become a potential result for the Random book navigation link; is that a good thing? We would want to wire {{BookCat}} to do the right thing, whatever we decided that is.
  • For a bookname, we would want something short and self-explanatory so it wouldn't be burdensome for the names of the subpages, but also something self-explanatory as a book name. For example, we wouldn't want to call the book Shelf because, although it might be tolerably clear what a page Shelf/Mathematics is supposed to be, it wouldn't be clear what a book called Shelf is supposed to be. The same goes for Shelves and Shelving, either of which one could just about imagine using as the name of a how-to book for home organizers. Likely the best choice, for standalone self-description, would be either Wikibooks Shelves or Wikibooks Stacks, which is slightly longer, and has no length advantage over putting it in project space instead of mainspace: Wikibooks:Shelves or Wikibooks:Stacks.
  • I'm not enamoured of using project space, as Wikibooks:Shelves or Wikibooks:Stacks. That would exclude those pages from a generic content search, and I'd rather include them in a content search.
One thing I would not want to do is to create a new namespace, such as was done for Subject:; that seems to me to just complicate the project infrastructure in a cumbersome way. --Pi zero (discusscontribs) 15:48, 7 April 2018 (UTC)
My current inclination is to set up the pages in mainspace using prefix Shelf:, with {{BookCat}} wired to categorize them in a hidden subcategory of Category:Book:Using Wikibooks. The current template {{subjects}} would, I suppose, be replaced by (or, morph into) one called {{shelves}}. --Pi zero (discusscontribs) 17:06, 7 April 2018 (UTC)
Personally I could treat several pages, but I don't want to choose for you if you intend to treat the hundreds of them, like you had done for the books categories.
Nevertheless, I would draw your attention on the facts that:
  1. a book containing all the shelves will take several hours to be built and synced, while been redundant of {{Category tree}}. That's why if it was just for me, I would rather delete the subjects and shelves pages (but not the subjects categories).
  2. a shelf books content will be impossible to print due to the server technical limits. For example, I couldn't automate Java Programming/Print version in Lua from the TOC, because of an overflow (and it's only 163 A4 pages long). Moreover, a few books had been cut to bypass the different resources limits, like Messier Index/Print Version/1 & Messier Index/Print Version/2. I notably remember a limit with Special:Book too.
  3. Wikibooks:Shelf:Mathematics would be counterintuitive because we don't usually publish the content into this namespace, and it won't be able to filter the shelves only. So a dedicated namespace would be the ideal solution for the search engine. We just have to include the "Shelf:" namespace in the default searches, and anyone will be able to uncheck it into Special:Search.
  4. But I don't think that a shelf in the random pages would be irrelevant.
Thank you for your attention. JackPotte (discusscontribs) 13:43, 8 April 2018 (UTC)
Sounds like we're largely in agreement. One remark re namespace usage: agreed shelves are rather too contentful for project space, the same seems to me true for category space. It's one thing to copy the shelf presentations into categories (we do this now for subject presentations, and went to some trouble to make it happen), but that's not the same as having the presentations primarily reside there. --Pi zero (discusscontribs) 00:23, 9 April 2018 (UTC)

┌──────────────────────────┘

One nuance, as I start to map out implementation details on this. At the very top of the soon-to-be-shelf hierarchy are a few pages that logically don't appear to be shelves. In the old bookshelf regime, the root was Wikibooks:Departments, and each page directly below it was a "department" rather than a "bookshelf". It's possible to make allowances for one "shelf" to be a subset of another, up to a point, but there's a scale at which it becomes really hard to imagine a "shelf" containing such a vast array of books. Even in the dedicated Subject: namespace, those top two levels of pages —the root and its children— are treated differently, in that they don't use {{Subject page}} and aren't supposed to ever have books directly filed in them. In the more recent discipline, there has been no enforcement of the principle of not filing books in the top two levels of subjects, as putting all those pages in a separate namespace naturally creates a sense of uniformity between what had been distinguished as "departments" and "bookshelves". However, in moving to give the lower echelons prefix Shelf:, one doesn't want to use that prefix for the pages at the two top levels. A likely solution is to treat those top-level pages as modules of a book. The shelves themselves would not be treated as pages of the book, though it would still make sense to file them in a hidden shelving category under the book category.

Re JackPotte's note that "a shelf books content will be impossible to print due to the server technical limits." If we want to generate a print version, it seems to me there should be no insurmountable technical problem generating a print version of the small book I'm describing, consisting of a splash page, departments page [maybe or maybe-not distinct from the splash page], and pages for the individual departments (but not the shelves). Although, I'm unsure whether we would care about a print version, since the book is something of an organizational device (reminiscent, in that regard, of "book" Engineering Tables). --Pi zero (discusscontribs) 14:24, 15 April 2018 (UTC)

Change from comma-based article counting[edit]

In light of recent events (described below), this community needs to discuss whether it wants to change the way content pages are "officially" counted on this wiki.

First, some background on "article counting": As described at mw:Manual:Article count and mw:Manual:$wgArticleCountMethod, MediaWiki-based wikis like this one have three possible ways of counting "content pages" (historically called "good articles" and now usually just called "articles"). All three counting methods require that a page be in a "content namespace" and not be a redirect in order to be counted as an article. The wiki may be set up to also require that the page contain at least one [[wikilink]] (the 'link' method) or at least one comma (the 'comma' method); otherwise all such pages are counted (the 'any' method). (BTW, the single-quotes are intentional, since single-quotes are used in the [large] configuration file that stores the relevant settings — search for the text "ArticleCountMethod" to see.)

This wiki uses the 'comma' method and has 3 content namespaces: the main namespace (which needs no "prefix" in front of page titles) and the "Cookbook:" and "Wikijunior:" namespaces. Therefore, the count of "content pages" on this wiki (which I will continue to call the "article count", mainly out of habit) nominally includes all non-redirects in those three namespaces that contain at least one comma. I say "nominally" because, in fact, what I just said is not actually true. (!) Allow me to explain…

Many bugs related to article counting have been found and fixed in the MediaWiki code over the years, but this wiki has (probably) never been recounted to fix the article count itself. This is mainly because the two maintenance scripts that are run to fix on-wiki statistics (which are called initSiteStats.php and updateArticleCount.php) do not actually implement the 'comma' method at all; instead, for performance reasons, they simply check for positive page length (in addition to the usual non-redirect and content-namespace criteria). Since April 2015, the second script (to recount only articles) has been run on the 21st of each month in order to keep the article counts more-or-less correct, even if relevant bugs remain in the code. But all Wikibooks wikis have been excluded from the periodic recounting because the English and Portuguese Wikibooks use the 'comma' criterion (and are the only Wikimedia wikis to do so — FYI, the Czech Wikinews, Chinese Wikinews, Gujarati Wikisource, Polish Wikisource, Serbian Wikisource, Serbian Wikiquote, and Wikidata use the 'any' method, and all other Wikimedia wikis use the 'link' method).

It appears that the 'comma' method is correctly implemented when pages are saved (i.e., created or edited), but that's laregly irrelevant if the article count itself has become very wrong because of past bugs. In any case, it doesn't matter anymore, because…

On February 15th and again on February 21st this wiki was recounted using the initSiteStats.php script. What this means is, the current article count no longer reflects the comma-based criterion, nor is it possible at this point to fix it (anytime soon) so that it accurately reflects the comma-based criterion (because there is no maintenance script to recount it in that way).

As reported at m:Wikimedia News#February 2018, the article count of this wiki changed from 57,843 (about 18 hours before the February 15th recount) to 79,075 (up to 6 hours afterwards), a 37% increase. Presumably the same thing would have happened if the 'any' method had been used, since there are no zero-length pages here. (Note that the "live" article count is 80,451.)

So, now we find ourselves in a situation where the current article count of this wiki is (approximately) "correct" with respect to a different criterion than the one we have assumed was being used to count articles here. This count may tend to drift a bit as the wiki is edited (since page-saves still use the 'comma' criterion), but it will never match the true 'comma' based count unless someone writes some relevant code and gets it approved for use. (This may be unlikely because searching wikitext for a specific string is resource intensive.) Meanwhile, there are plans to periodically recount all stats on all Wikimedia wikis, including Wikibooks, which would mean that the count here would be periodically be reset to this weird "positive-length" based count, anyway. Although the current count doesn't technically match that given by any of the official, documented counting methods, as a practical matter it approximately matches what the 'any' method would give.

So, should we switch from the 'comma' article-counting method to the 'any' method, since that is essentially the situation we find ourselves in now?

(For additional context, see the discussion at phab:T59788 and the information at m:Article counts revisited.)

- dcljr (discusscontribs) 08:48, 28 February 2018‎ (UTC)

The following two posts appear to account for the current configuration:
--Pi zero (discusscontribs) 02:23, 1 March 2018 (UTC)
It looks as if we decided to switch from links to commas in February 2011 because we deemed links unsuitable here, and then the any option was added later than year. I wonder whether the two events are related. I see the technical suggestion of commas was provided to us at the time by bawolff; @Bawolff: do you have any thoughts on this? --Pi zero (discusscontribs) 13:07, 1 March 2018 (UTC)
Comma count method has been an issue for a long time, as its difficult to recount. I'd reccomend using the any method if the community finds that acceptable. Bawolff (discusscontribs) 22:04, 1 March 2018 (UTC)
Support. Situation clarified; I'm comfortable. --Pi zero (discusscontribs) 18:10, 3 March 2018 (UTC)
Comment . Good to see there's no objections to this yet. Be warned, though, that a decision to remove comma-based counting entirely from the software (phab:T188472) is moving ahead faster that I had anticipated, so if anyone does object to this change, speak now… - dcljr (discusscontribs) 00:49, 4 March 2018 (UTC)

FYI, comma-based article counting has been removed entirely from the MediaWiki software, and this wiki has been switched to use the 'any' article-counting method (phab:T188472). - dcljr (discusscontribs) 03:07, 8 March 2018 (UTC)

Additional functionality to comment/annotate[edit]

Hi, met recently with SvNicholls, Head of Humanities at Teesside University and she thought Wikibooks would be an excellent platform for online courses for students to contribute Open Textbooks on courses such as the Creative Writing MA. The one thing we discussed that might be useful is for the ability to comment (and respond to comments) on drafted pages as you can do on Google Docs and also how you can do in MS Word using their annotate function. Might be missing something but currently I could only see the ability to use Visual Editor's 'Comment' function exists but that this is fairly limited with comments only visible in Edit mode. I think having extra functionality around annotating and commenting on the text would be very useful on WikiBooks so am happy to create a task on Phabricator if others think this would be welcome.Stinglehammer (discusscontribs) 10:38, 30 April 2018 (UTC)

@Stinglehammer: I would avoid VisualEditor if I were you.

Each page has a talk page; that's the primary forum for discussion of a given wiki content page. --Pi zero (discusscontribs) 12:04, 30 April 2018 (UTC)

Source Code[edit]

There is a persistent problem with source code in Wikibooks. It is very prone to vandalism or introduction of errors, as only a small subset of editors may understand the content and even a smaller one would be inclined to check each edit and the implications to the "correctness" or "compilability" of it. I proposed sometime ago a source code protection for only register editors with the review flag but I guess no one cared about to address the issue. That can take the form of (or a mix of) a Wikimedia software solution or a policy that empowers book communities and reviewers. Another implication to this volatility is also in regard to code licensing (copyrights), but that can only remain a consideration for now and be addressed independently. --Panic (discusscontribs) 05:40, 2 June 2018 (UTC)

Usually the source codes from Category:Subject:Computer programming expose one concept, so they are too small to be compilable or copyrighted. But if someone posts a full 100 lines page of code in one commit, I google that content. Compiling it is pretty quick with https://fiddles.io/. JackPotte (discusscontribs) 11:43, 2 June 2018 (UTC)
It is hard to define what size wise can be copyrightable without a legal challenge, but as natural languages, the rules should be the same, so a simple phrase (ie: routine) can have rights associated. In any case the rights is not the primary concern, as I stated. But I watch several programs (not simple routines) on Wikibooks and several of those have a history of people claiming rights over them (signing into the contribution), I have also watcher rewrites to make a claim and have reverted unreasonable claims. In any case protecting the pages would reduce a lot of wasted work on this area. It would also help enable resume of work, as I'm aware of at least 2 other editors that became frustrated but the code vandalism that happens on the project. I have also stopped contributing code and checking in minor code edits due to this (vandalism/errors) issues (it becomes time consuming to recheck variable changes and non obvious logic). --Panic (discusscontribs) 12:25, 2 June 2018 (UTC)
I understood the question to be partly about protection in the technical (rather than legal) sense. The level of technical protection you're talking about sounds like semi-protection. However, the platform provides protection per page, and I don't see how anything finer-grained than that would avoid becoming far too complicated to be humanly useable (defeating the purpose of wikis). Per-page is the level of such things naturally supported by a wiki; which is also inconvenient over at Wikinews, especially when we need to separately review-and-revise multiple pending edits to a published article. I do not however see anything to be done about it, and I'm rather certain anything of this sort attempted by the Foundation would be catastrophically counterproductive (due to their fundamentally misguided goals).

A possibility I have used a couple of times, and have hoped to make much better use of at some point in the future, is some sort of notification category, building perhaps on {{evalx}} and even dialog. The idea is, broadly, that pages check themselves for some expected property (for which {{evalx}} is very useful), and if the property is not as it should be, they use a category to flag themselves out for inspection by a human operator. Then, providing good semi-automation to assist the human operator is where dialog ought to come into play, if I can just get the practical use of dialog to a more sophisticated level. The one case of this I have in operation on Wikibooks is Category:Attention needed (allbooks), which in the coming upgrade of the subject hierarchy (which I'm still in the process of cautiously designing) looks to be replaced by Category:Book:Wikibooks Stacks/Attention needed. --Pi zero (discusscontribs) 12:38, 2 June 2018 (UTC)

In the only book with code I've made major contributions here, most source code is transcluded (resides in its own page and is included with the text, probably why the problem is made more evident to me as all edits are more clear in function), this helped reuse of examples and maintenance. If for example it is somehow set for reviewer flag level edit protection there is no exclusion of contributions to the "normal content" edits. The change could be in a per book upon request from a reviewer active on that project, even setting some categories for that admin job, this also eases policy change as it can be included on the particular of the reviewer policy. I don't foresee problems as reviewer are invested editors on the project, often project specific and most are contactable.
For a patrolled/major editor keeping a large number of these code pages under control is impossible, from indentation changes, format, wikitext for color edits to real code with time a large portion of the code easily becomes corrupted. Page reviews helped at first but at the same time as the number of code changes increased in number or complexity I chose to cease reviewing those edits, sadly to the detriment of readers (since we publish unreviewed edits).
The present situation also made me stall a practice textbook (very good to get new editors on the project, and I had planed to link it up with Wikiversity). It seems still to be popular in its trashed state, but I couldn't spend the time reviewing all the re-wrights of already accepted/verified solutions.
How complex or easy the solution becomes depends on software limitations and/or admin work, in the end, the reality is that the status quo is not sustainable. Just check the code edits on the algorithms book (and their history for a look on the energy spent keeping it right and often failing) if you have the patience. I also noticed that some books covering less popular languages (or less edited) get less of this error creep (like the ADA book, even if I don't watch each page I haven't seen it on the logs), all others suffer form the situation. --Panic (discusscontribs) 00:40, 3 June 2018 (UTC)
There is no protection level between semi-protect (only autoconfirmed users) and fully protect (only admins). I would be (pleasantly) surprised if the Foundation would allow introduction of a protection level for only reviewers. We do have the technical ability to set any page so that the most recently sighted revision is visible, as we have done for all the pages at Wikijunior. Unfortunately, that doesn't help with a transcluded page: even though the page itself displays the most recently sighted revision, the most recent revision is, I believe, transcluded regardless of whether or not it's sighted.

There are, however, various opportunities for mild intervention. In addition to the sort of attention-needed categories I mentioned above, there might be an opportunity to transclude a code page through a template that, in some manner or other, prevents unauthorized changes to the code from appearing prematurely on the transcluding page. --Pi zero (discusscontribs) 03:32, 3 June 2018 (UTC)

Now under construction: Wikibooks Stacks[edit]

As part of the infrastructure overhaul I've been doing for, at this writing, just over 23 months, and following from the previous discussion here in the ongoing series of threads (link), I'm now developing a replacement for the current subject hierarchy, in the form of a book called Wikibooks Stacks.

I'm not currently asking for help with this, tbh. Somewhat embarrassingly, given the collaborative nature of wikis, just atm I really need to do this carefully, step by step, myself, because there's still new design work involved at each step. But I do want to let everyone know what I'm doing, and perhaps folks here will offer advice (or point out that I'm making a huge mistake somewhere!).

When I'm all done, all our 3000-or-so books will be filed in both the "old" subject hierarchy and the "new" stacks, and I'll be able to do the equivalent of flipping one of those big high-voltage switches and suddenly the categories visible on each book main page will be shelves instead of subjects, and then I can start the process of carefully mothballing the old subject pages, one by one. Then it'll be time to start in earnest on the final(?) stage of this multi-year overhaul of our infrastructure, the introduction of topical categories that list pages as well as books, which will enable us to provide much better targets for incoming links from sister projects, including from Wikipedia.

Grouping all of this machinery in a book is more convenient, organizationally, than the Subject: namespace, as it happens. The new pages, equivalent to subjects, have name prefix Shelf: or, at the top level, Department:, which are not recognized by the wiki platform as namespace prefixes, so these pages are all technically in mainspace, as is the book. Our infrastructure templates such as {{BookCat}} and {{BOOKNAME}} know to associate these name prefixes with book Wikibooks Stacks, which is convenient because most of the pages involved don't have to have the name of the book built into them at all, they can just use markup {{BOOKNAME|Shelf:}} (which expands to Wikibooks Stacks). Shelves correspond to subjects that use {{subject page}}, departments to subjects that use {{root subject}}.

There are shelf categories, each with an associated allbooks category, just as there are subject categories with associated allbooks categories. When I set up the machinery of the subject hierarchy, I arranged that when any of the pages involved detected a problem, it would flag it out, and provide buttons to help a human operator implement likely actions to fix it. This time around, I've made some improvements to this semi-automation while I was about it.

I also very much want to arrange for dialog-based assistants to replace the older-style editing buttons (with the older-style buttons reappearing if the dialog tools are not detected — thus, graceful degradation when things aren't working right). This would be very cutting-edge use of the dialog tools, and I very much want to learn as much as I can from the experience, about how to make effective use of the dialog tools. Which is actually part of what's holding me up just atm: I could be marching forward with setting up shelves, but then I'd be missing out on this major opportunity to gain experience with dialog. --Pi zero (discusscontribs) 19:51, 3 June 2018 (UTC)

Redundant language interwiki links[edit]

Once again today, someone has removed the local interwiki links because they were redundant of Wikidata. Many of them are moreover incomplete, and the other projects editors don't update them, because the English Wikibooks is the only project I know which promotes these good old links since 2015.

The consensus from there wouldn't imagine the frequent differences between for example our links from Wikibooks:Statistics and the Wikidata ones, which in addition, are not limited to the other Wikibooks. So I propose to adopt the same system as the other Wikimedia projects to save some time and accuracy. JackPotte (discusscontribs) 18:01, 5 June 2018 (UTC)

Nothing has changed to invalidate any of the reasons I've objected strenuously to mass-destruction of local interwiki information. (In recent months I've noted —with no bad intentions anywhere in sight, just the error-fostering design of the system— large-scale corruption of Wikinews interwikis by subtle bot-action on Wikidata.)

I do very much want to implement a dialog-based assistant to maintain the relationships between local interwikis and Wikidata. Having trouble, day to day, conjuring time and energy for the tool development involved. --Pi zero (discusscontribs) 18:20, 5 June 2018 (UTC)