(Redirected from Wikibooks:PROPOSALS)
Wikibooks Discussion Rooms
Discussions Assistance Requests
General | Proposals | Projects | Featured books General | Technical | Administrative Deletion | Undeletion | Import | Permissions

## Now under construction: Wikibooks Stacks

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)

Progress report: All our books have been shelved; they're also all listed in subjects. The shelf categories are hidden, the subject categories are visible; but I'm now in a position to switch that, so the shelf categories are visible and the subject categories hidden. Then I can start shutting down the subjects, which also has to be done manually. Strangely, I've got a discrepancy between the number of shelves and the number of subjects, whose cause should eventually come out during the manual shutdown. I'm not sure what to do about possible incoming links to subject pages that are now going to be either nonexistant or redirects. --Pi zero (discusscontribs) 02:26, 29 September 2018 (UTC)
Cheers for all the work you have made already. I noticed two things which I'm not sure whether they are glitches or not: 1) Departments do not list any featured books. 2) Under Wikibooks Stacks/Departments the Wikijunior department correctly lists the Wikijunior shelf, but the Help department does not list the Help shelf. -- Vito F. (discuss) 23:46, 10 October 2018 (UTC)
On the second point, actually the link provided is to the help shelf, rather than to the help department. I'm unsure whether that should be treated differently, or if instead the wikijunior department should be treated differently. --Pi zero (discusscontribs) 04:03, 11 October 2018 (UTC)
I think I've got the department featured books problem fixed. --Pi zero (discusscontribs) 06:43, 12 October 2018 (UTC)
I've improved both of those displays on the departments page. --Pi zero (discusscontribs) 12:44, 13 October 2018 (UTC)

## Merge Template:One-page book into Template:BookCat

The one-page books like DBMS don't need a dedicated category like Category:Book:DBMS, because categories are meant to gather groups of pages.

That's why I propose to merge Template:One-page book into Template:BookCat, and to replace this couple of templates by {{BookCat|1p=yes}}, so it would add Category:One-page books and not Category:Book:. JackPotte (discusscontribs) 12:57, 1 August 2018 (UTC)

It's an interesting thought; off hand, though, I'd think it apt to make infrastructural coding more complicated, multiplying special cases depending on features of a book. It's simple to assume if there's a book main page, there's a book category. --Pi zero (discusscontribs) 13:24, 1 August 2018 (UTC)
That said, it might be useful to do a cross-check in {{BookCat}} regarding the number of pages in the book category versus membership in Category:One-page books. --Pi zero (discusscontribs) 13:26, 1 August 2018 (UTC)

## Making use of autoreview

That's just a permission which is rarely used which I think can be made into better use. Currently it is a rarely-used permission granted my sysops under their discretion (I, for one, give the permission when I feel that user is contributing on few pages).

As the much more popular reviewer permission is auto-granted upon meeting some conditions, I propose that the autoreview permission also be auto-granted upon meeting a lesser set of conditions.

Maybe something like

1. 35 edits 30 reviewed edits and
2. 10 days old account?

The conditions are designed in such a way to ensure that it is not too hard to achieve while keeping a barrier for bad-faith users.

I also propose that users who already have autoreview and later gain reviewer should (automatically) have the autoreview flag removed, as reviewer is a superset of autoreview. I plan to be manually doing this very soon to 'clean up' the list of autoreviewed users (which in itself is few).

Leaderboard (discusscontribs) 07:11, 14 August 2018 (UTC)

The best would be to get the whole picture before deciding the rights limits. I think about the sysop candidates, the voters limits, and even meta:Admin activity review/Local inactivity policies.
That's why I had manufactured a kind of state of the art on the French projects myself, and then we have voted to uniformized the first steps numbers on the French Wikiversity to 100 editions plus one month old account (for voting to anything and getting the autoreview flag).
Anyway, 35 seems very low to me, especially with the typos maintenance. So we would have to decide the meaning of a significant edition, and its value (10 pages of qualities = 1,000 typo corrections?). JackPotte (discusscontribs) 14:54, 14 August 2018 (UTC)
I see three suppositions here:
1. that the only concern with conferring autoreview is bad-faith edits;
2. that autoreview of one's own edits, when compared to review of others' edits, becomes safe at a significantly lesser level of project experience; and
3. that the project suffers significantly from the cost of dealing with accumulating un-autoreviewed edits during the interval between sufficient project experience for autoreview, and sufficient project experience for general review.
In case it's not perfectly clear, let ${\displaystyle x}$ be the amount of project experience where it becomes safe to give the user autoreview, and ${\displaystyle y}$ the amount of project experience where it becomes safe to give the user review. The ratio between the two, ${\displaystyle x/y}$, must be significantly less than one, or we wouldn't want to complicate things by conferring autoreview separately. If this ratio is, say, 0.95, that means the amount of project experience where it becomes safe to confer autoreview is 95% of the amount where it becomes safe to confer general review, and if the ratio is that high, I for one doubt it'd be worth it.

The purpose of requiring project experience before conferring review is more than just filtering out bad-faith editors. The review autopromotion threshold is concerned with the user's acclimation to the local culture of the project, as distinct from other projects, such as Wikipedia (from which cultural hegemony is a perennial problem for the smaller projects). In my experience, though, a project-inexperienced user is more likely to run barefoot through the project imposing cultural misapprehensions to their own edits. Therefore, I'm inclined to reject supposition (1), and therefore to mostly reject supposition (2).

Even if the ratio ${\displaystyle (y-x)/y}$ were significantly less than one, I would still be dubious of supposition (3). With the primary exception of Wikijunior, review on en.wb just isn't that urgent. We certainly do want to deal with it, but when we fall behind it's not a disaster, unless of course the edits we haven't reviewed are severely problematic. We try to notice problematic edits when they happen, and review is our safety net for when we don't catch them immediately. If it takes a while for us to collect things that get caught by the safety net, that's still better than not having the net. --Pi zero (discusscontribs) 17:16, 14 August 2018 (UTC)

On a purely practical point, I question whether it is worth the effort to request automation of the allocation of autoreview given how few people request it. To extend Pi zero's thoughts, we need to be cautious with setting the level too low. Often the most problematic editors are class projects who can rack up 35 edits in an hour which are often full of copyright violations and other problems. Removing the requirement to contribute more broadly before edits are automatically accepted reduces our chance to course-correct these editors. The impact can then be mass deletion of their work later. QuiteUnusual (discusscontribs) 17:22, 14 August 2018 (UTC)

┌──────┘
Thank you all for your views.
One valid concern I see is the concern of sufficient project experience before granting autoreview, and hence I'll make a small modification to my proposal: instead of just 35 edits, there should be 30 reviewed mainspace edits (excluding talk for instance). The reason is that the autoreview permission is meant for those who make contributive edits to only a few books, and there should be evidence of that. This should also solve the issue of 35 edits being too less; it's far tougher for 30 reviewed edits to be bad than 35 unreviewed edits.
The lack of clear documentation regarding autoreview is the major reason why so few people request it. I remember once querying about autoreviewing edits way back in 2014 in one of my RFP's, and some users wondered what that is. The RFP did not mention autoreview, and the related userright template did not mention it either then.
your comment on "decide the meaning of a significant edition, and its value" got me thinking, and I tried to model this. A quick and dirty one gave me something like (where ${\displaystyle }$: average size of each edit, E: no of edits required): ${\displaystyle E=50-(\ln )^{2}}$ (with constraint ${\displaystyle \min(E)=10}$). That could also help counter the issue of users trying to evade the rule by making small bad edits.

Leaderboard (discusscontribs) 18:01, 14 August 2018 (UTC)

Your proposal does not appear to be solving any existing problem. Clearly there are drawbacks, and we get nothing in return for those. --Pi zero (discusscontribs) 18:22, 14 August 2018 (UTC)

## Proposal to delete Simple English Wikiquote and Wikibooks

There is a now a proposal to delete Simple English Wikiquote and Wikibooks. Agusbou2015 (discusscontribs) 22:29, 26 August 2018 (UTC)

Proposal withdrawn, and the projects will not be deleted. StevenJ81 (discusscontribs) 14:51, 28 August 2018 (UTC)

## Restricting page creations and raising autoconfirmed limit

### Restrict new page creations to users with account

I propose that the ability to create new pages in the main namespace be taken away from anonymous users. The reasoning is simple; ~100% of pages created by them are nonsense, test edits or otherwise get speedily deleted. While it may raise concerns that it is against the principle of free access, I believe that this restriction is justified.

This change is not without precedent; en.wikipedia currently restricts general page creation to autoconfirmed users.

For what it's worth, I do not propose requiring autoconfirmed; while that is certainly an option, I think there could be genuine cases where users (eg, as part of a class project) create a new page immediately.
(If that's what you prefer, then it will be necessary to create a "page creation request" option wherein users could request pages for creation to be reviewed by admins in a queue)

I had already thought about that time when the most part of the anonymous new pages would be trash, impossible to handle by our team. Today, I don't think that we've reached this critical point but I think that the problem isn't limited the the creations: all modifications are concerned.
My URL abuse filter for the newcomer has stopped the spammers, so we "just" have to delete around 10 test pages per day, which seems doable to me in order to preserve the wiki spirit, where anyone can publish anything valuable quickly. JackPotte (discusscontribs) 08:56, 27 August 2018 (UTC)
Maybe, but has any IP user ever published a sensible article? Modifications on its own I can understand; many IP users do make contributive edits, but I can't see that for page creations. JackPotte's filter army (especially filter 38) is incredible; I'm surprised with the junk which users try to insert into Wikibooks which one never sees (and hence I don't mind the occasional false positive on that). But that filter does not help with creating blank or gibberish articles. Leaderboard (discusscontribs) 09:12, 27 August 2018 (UTC)
IPs do make useful contributions here and there. I think there might be a book or two around that were created by IPs, though I couldn't lay my hands on them readily. --Pi zero (discusscontribs) 10:38, 27 August 2018 (UTC)
Just stumbled across an example of a book created by IP, How to Type. Makes me wonder if there are more of them than I'd thought, since I happened across one so soon after the question was raised. --Pi zero (discusscontribs) 13:15, 27 August 2018 (UTC)
The book in question consists of only three articles and was created way back in 2011 (were things different back then?). While admittedly still a surprise for me, I am inclined to think that this is a rare instance of an IP who has created pages which would come in the top 0.1% of all mainspace pages created by an IP. Leaderboard (discusscontribs) 13:53, 27 August 2018 (UTC)
I just crossed paths with another one: How to Tie a Tie. As you might guess, where I found those two has to do with the partly-alphabetical order in which I'm doing my current walk through the collection.

Beware of convenient reasons for disregarding information that doesn't fit your current thesis. I suspect you'd find the whole Wikibooks project was most active in its early years and has slowly declined since —a pattern whose cause, if it's really there, may be a deep, complex mix of factors— so it may be that the starting date of a book has good odds of being some years ago regardless of who created it. Also, asking whether only 0.1% of IP book creations are useful may be asking the wrong question; not only are we intensely interested in not turning away positive contributions, but we are also crucially interested in not turning way positive contributors, both because we want to retain them as contributors if possible —they are the pool from which the next generation of Wikibookians must come, if it's to come from anywhere— and because, regardless of whether they stay in the long run, we want them to come away with positive feelings about the project so that those feelings spread outward from them memetically to other potential contributors. --Pi zero (discusscontribs) 15:02, 27 August 2018 (UTC)

### Introduce edit count limit for autoconfirmed

The current Wikibooks policies state that autoconfirmed users need to be four days old. There are a few issues with that:

1. It does not make sense for users who have never edited to be able to edit semi-protected pages by just waiting.
2. Because users do not need to edit to get autoconfirmed, some edit filters (eg: the often-hit filter 38) have to be modified to take edit count into account. This means that users often get unknowingly caught, and we can't simplify things by just saying that users need to get autoconfirmed to insert external links.

Hence I propose that users need to make a few edits (in addition to the four-day rule) in order to get autoconfirmed status. I think 5 edits would do, but some other wikis use 10, so I leave that to you. Leaderboard (discusscontribs) 08:33, 27 August 2018 (UTC)

That's what Wikibooks:Autoconfirmed users says; I've no idea whether it's true. And I'd also be interested, before changing our criteria, whatever they now are, in how much trouble we now get from autoconfirmed users who would be excluded by the altered criteria. --Pi zero (discusscontribs) 10:46, 27 August 2018 (UTC)
It's true; I remember one instance of an user caught by the edit filter; he had made only one edit and was listed as autoconfirmed. Leaderboard (discusscontribs) 11:42, 27 August 2018 (UTC)
Playing devil's advocate, an autoconfirmed class that doesn't require any edits is still a potentially useful preliminary filter against a large class of casual troublemakers with short attention span; a determined troublemaker with a nontrivial attention span can get past any plausible set of autoconfirmation criteria. --Pi zero (discusscontribs) 13:24, 27 August 2018 (UTC)

## Tag Proposal

Tags are used throughout Wikibooks to draw attention to something that needs attention, for example, there's something not neutral about a book, a fact is in dispute..etc...

At present, the current mechanism for tag use is to tag it and discuss the changes and arrive at consensus either for or against the requested change. However, what happens if something is simply tagged without discussion, like this example, which really did happen. This article was tagged by a bot that is no longer active back in 2007. No discussion was started and the tag remained. That's 11 years with no discussion and the tag still present. Or, take for instance this example ] which was tagged in 2006 by Sirakim, and again no discussion was ever started by that user or any other user.

While I commend the users for tagging the book, without discussion, there can be no consensus, and without the consensus, the requested changes (if they're actually requested at all ) can't be made. The current thought on this is to simply leave the tags in place unless consensus exists to have them removed. However, with the tags staying on the books for years without discussion, or with a dead discussion, they serve to make the books less likely to be read. Since the end goal of a book is for it to be read, these tags without discussion or with dead discussions (at least 3 years old like this one which was posted in 2012 and has had no responses whatsoever) , actually fail to serve that purpose. They , in fact, serve to make the books less desirable to be be read. In light of that , I'd like to make a proposal.

My proposal is this, that tag can be removed in cases where they are left without a discussion on the talk page, or if a discussion has stopped for a period of at least 3 years .

My rationale is: That the tag on the page without a discussion is useless, no one can read the mind of the person placing the tag thus making the tag useless. In the case of a discussion that's dead, like 3 years dead, even though there is no time limit, allowing 3 years for a discussion and coming to no conclusion makes the tag useless as well. Further by allowing tags to remain for years without any removal leaves open the concept of tagging as harrassment (en.wikipedia has had this problem and for that reason, allows for IAR removal of tags if it's been determined that they serve no purpose other than to harass.)

My remedy for this would be that the tag could be removed by an user, if , within 3 years there is either no discussion or the discussion has died without consensus, without predjudice, meaning the tag can be placed back in, as long as the editor is wiling to start a discussion and explain why this tag needs to be placed on this book.

Personally, I really think it should be a case of IAR, but as User:Leaderboard has objected to my doing this, I thought it prudent to start a discussion to see if a consensus might be raised.

So, what do you think ? 16:18, 29 August 2018 (UTC)

You're misunderstanding some important points, here. (I commend your presentation, btw.) It's taken me years to grok some of this, and I rather welcome the opportunity to try to lay some of it out where it can be seen as a whole.
• Your first statement is incorrect; you say tags are "to draw attention" to a problem, but no, that is not their primary purpose. Their placement is chosen to draw attention, but that drawing of attention is merely a secondary enhancement to their primary function. Their primary function is to declare that in somebody's judgement, there is a problem. It would be grossly destructive to erase our institutional memory of such concerns, and would to a disservice to readers, to potential writers, and to the books involved.
• Wikibooks has fundamentally different community structure that Wikipedia.
• If you think of Wikipedia, Wikibooks, and Wikinews (I'm most familiar with those three projects, and have found them a useful progression to consider) simply as coherent projects, obviously Wikipedia is the largest, Wikinews the smallest, and Wikibooks of intermediate size. However, Wikipedia is, to a significant extent, a uniform pool of millions of articles, and it's expected that individual users, in general, roam moderately freely across many articles. On Wikinews, a given news article is only worked on by, typically, two people — a reporter and a reviewer. And Wikibooks has yet a different structure: in a sense, Wikibooks isn't a single project at all, but rather a confederation of about three thousand micro-projects, most (if not all) of them so much smaller that Wikinews is gigantic by comparison. These micro-projects are called "books". Each of them is far too small to warrant a whole administrative infrastructure on its own, and despite their many idiosyncracies they do have some properties in common, so they band together for a common administrative infrastructure. There is a fairly small community of users here who concern themselves with Wikibooks as a whole —some of those users are admins, a bunch more are not— and then each book has, at least in concept, its own community. However, the community of a book is profoundly different from that of a large project like Wikipedia, or even than the central-infrastructure community of Wikibooks.
• Small projects, I have observed, have greater respect for users who came before; as project size shrinks, respect for the positions of past users rises. Wikipedia has far less; Wikinews has more; and on individual books, this effect reaches its highest form. It's not uncommon for a given book to have only one major contributor at a time; adopting a book is a common process here (one I've been through myself, both partial adoption and full adoption). There might be only one major editor on a book in a given year, or a given book might go for years without a major contributor. When one comes to a book, one generally puts much thought into understanding the approach to the book taken by one's predecessor(s) on the book, and if one does make significant changes it's after careful consideration and some notification and conceivably even inquiry on one or more user talk pages. It's sort-of as if past editors on a book are ghostly participants in current decision-making.
The idea of removing tags on book after some fixed number of years is just fundamentally contrary to both the time-scale and the attitude toward predecessors. --Pi zero (discusscontribs) 17:19, 29 August 2018 (UTC)
I must agree with Pi zero's first point; tags are to inform users that there is a problem as much as it is done to attract attention.
However, I do think that tags should not be kept for too long; certainly not 11 years. There should be some appropriate discussion made to that effect (but not removal after x years like what you suggest); after all, a freshly-placed tag could be taken more seriously than a tag which was kept ages ago. Leaderboard (discusscontribs) 17:54, 29 August 2018 (UTC)
To be clear —this may be compatible with what you're driving at— seems to me if a tag has been around for 11 years that's certainly a positive motive to do something about it, but how one goes about that is the same as it would be if one had acted much earlier.

An old tag might still be taken seriously, I think; it's entirely dependent on the specifics of the situation. --Pi zero (discusscontribs) 18:51, 29 August 2018 (UTC)

Sounds like User:Leaderboardand I are thinking in approximately the same direction, that tags should just languish forever. What I'm saying, is if a tag is placed on the page, whomever places the tag should start a discussion and state what's wrong. A tag without a discussion, and no additional comments on the tag means that we can't see what the tagger saw. I'm certainly not about to remove a tag that was placed on a day ago, even a week ago or a month ago where a discussion was started but no discussion is continuing, we all have real life to deal with :) . But if it's left on 3 years with no discussion started or the discussion has died off, sure. That's time enough to have at least made some change or reach some consensus, dont' you think.

If that doesn't sound right, we can set some other criteria to it, like a greater year length with no discussion or a dead discussion and no consensus is reached, or some other kind of criteria. I'm certainly willing ! 19:48, 29 August 2018 (UTC)

One of Wikipedia's faults (amongst others :-) is its red tape. Bureaucratic rules. I'd like not to import that feature from Wikipedia to other projects. If one has a case of that sort to remove a tag (if I'm following you, the argument is essentially, the tagger didn't explain, I don't see the problem, and after all this time there's no evidence that anyone else saw the problem and either commented or attempted to solve it, either), I'd suggest making the case for tag removal on the associated talk page, perhaps inviting comments from people (projects reading room possibly?), give it some time, and after a while, then remove the tag. Or some variant on that, depending on particular circumstances. --Pi zero (discusscontribs) 21:16, 29 August 2018 (UTC)
Keep it simple in my opinion: If the book is inactive, and the person who placed the tag is inactive, and you as an informed, active, editor think that the tag is no longer required or was misplaced originally then remove it with a comment on the talk page. QuiteUnusual (discusscontribs) 08:06, 30 August 2018 (UTC)
User:QuiteUnusual I agree with the keep it simple approach, and that's what I originally intended to do (Kind of an IAR thing we have over at Wikipedia (IAR = Ignore all rules) ). In fact, one of my first edits was this one, where I invoked IAR (with a detailed explanation of why I was removing the tag), in this case, Mike's Bot tagged the page as being non-neutral, back in 2007, and opened no discussion, nor had anyone else, and the user running Mike's bot has retired, so he can't be asked why this page was tagged, so I thought this was a good candidate for an IAR removal under those circumstances, that edit was reverted . I was messaged about it on my page and after a quick discussion I stated I wouldn't touch the tags on any page for the time being, that's the genesis of this whole discussion.

There's no actual mechanism for removing tags, so I thought it might be a good idea to have some sort of mechanism for doing so when it's obvious that nothing is being done about the tag and more than enough time elapsed. Yes, I agree that there's plenty wrong with Wikipedia, that's why I'm over here and not over there, but that doesn't mean throw the whole model away, there are some things they do that are actually pretty useful, like IAR. Speaking of, what criteria would you use to determine if a tag should remain on a page or be removed ? 14:01, 30 August 2018 (UTC)

## Conversion of Books into Other eBook Formats

While books on Wikibooks are, in many cases, supplied in both webpage and PDF formats, these formats are not necessarily portable to all use-cases. In particular, PDFs do not natively support word-wrapping, which makes them difficult to read on small devices or with bad eyesight. I propose that, in addition to offering in-browser and PDF documents, Wikibooks should offer either (or both) ePub format books and/or easily downloadable archives of the webpages that collectively make up individual books. These formats are simple, widely supported, and allow for both easy distribution and increased accessibility while offline. Thank you for your consideration. --198.119.59.10 (discuss) 15:49, 18 October 2018 (UTC)

Actually it has already been implemented in 2012: Special:Book. JackPotte (discusscontribs) 21:10, 18 October 2018 (UTC)