Open main menu

Wikibooks:Reading room/General

< Wikibooks:Reading room(Redirected from Wikibooks:CHAT)
Replacement filing cabinet.svgArchivesWikibooks Discussion Rooms
Discussions Assistance Requests
General | Proposals | Projects | Featured books General | Technical | Administrative Deletion | Undeletion | Import | Permissions

Contents

Welcome to the General reading room. On this page, Wikibookians are free to talk about the Wikibooks project in general. For proposals for improving Wikibooks, see the Proposals reading room.

New user group for editing sitewide CSS/JSEdit

When the Foundation acts to disempower the volunteers, they should admit that's what they're doing. Honesty is very high on my priority list. --Pi zero (discusscontribs) 13:31, 30 July 2018 (UTC)
We just have to add all the admins into this group for a start. JackPotte (discusscontribs) 14:10, 30 July 2018 (UTC)
That seems like a reasonable measure to me. The creation of the group would otherwise constitute a revocation of privileges from existing admins without approval of the local community. @QuiteUnusual: What procedure do we need to go through (if any)? Official hoops to jump through? I seem to recall that on en.wb (unlike en.wn) local 'crats don't have the power to toggle the admin bit, but since I'm not a 'crat here I can't tell for sure whether the same is true of the new group. --Pi zero (discusscontribs) 15:18, 30 July 2018 (UTC)
I think that this privilege should be restricted to the bureaucrats only, rather than to all sysops. Let's face it: the permissions discussed aren't small in effect. And not all admins need (or even know how) to use it. This should at least put the 'crats group to some value rather than being some superfluous extension of sysop. Leaderboard (discusscontribs) 15:35, 30 July 2018 (UTC)
@Leaderboard: That's definitely too restrictive. I, for example, am not a crat on Wikibooks, and I'm engaged in an occasionally-intensive, multi-year javascript-based wiki infrastructure development project; it'd be kind of a disaster for me to not be able to edit the javascript files; and I'm somewhat involved from time to time in the CSS, too. And JackPotte does maintenance on our codebase; it would be detrimental to the project for JackPotte to not have those privs. Frankly, I think any admin can be trusted to make judgements about when they're qualified to tinker with the js or css. We could reasonably have an arrangement where an admin is granted the interface priv only if they request it; that way, admins who judge themselves to have no need for the bit would not have it on their accounts, and there'd be no problem as long as whoever turns on the bit for them was careful not to respond to a request from an admin account that had already been compromised at the time of the request. --Pi zero (discusscontribs) 17:03, 30 July 2018 (UTC)
All such admins should get bureaucrat-ship. If you have a need, get it. I'm looking for the bureaucrat flag to be more than just a useless permissions-granter, and this is one of the better ways to ensure the same. Indeed, admins who "could reasonably have an arrangement where an admin is granted the interface priv only if they request it". Leaderboard (discusscontribs) 17:12, 30 July 2018 (UTC)
@Leaderboard: Two things:
  • That seems backward; the point of splitting off the interface priv is so that an account doesn't have to have excess privs on it that aren't needed, so it would run counter to that to force a user to become a crat in order to acquire the interface priv. The amount of trust by the community implied by granting adminship seems to be exactly the amount of trust for a user to be able to decide whether or not they should be exercising the interface priv.
  • I've been involved in several crat RFPs, including one where I became a crat myself on en.wn, and I have to say it's a huge hassle and a royal pain for a small project. Imho it'd be a terrible idea to require users to go through that sort of hell just to get an interface priv that, as I've now remarked a number of times, is quite within what an admin's judgement can be trusted on.
--Pi zero (discusscontribs) 18:28, 30 July 2018 (UTC)

Given the main point of a crat is to judge consensus and grant admin rights it makes no sense to me to make them the only people able to edit the interface especially as very few projects have any crats. I think we should just add the right to any admin who asks if the crat is willing to, rather like adding reviewer or importer. QuiteUnusual (discusscontribs) 15:54, 25 August 2018 (UTC)

Bureaucrats can toggle interface admin here by the way. QuiteUnusual (discusscontribs) 16:38, 25 August 2018 (UTC)
Ok, let that be the case. Leaderboard (discusscontribs) 17:03, 25 August 2018 (UTC)

Editing of sitewide CSS/JS is only possible for interface administrators from nowEdit

(Please help translate to your language)

Hi all,

as announced previously, permission handling for CSS/JS pages has changed: only members of the interface-admin (Interface administrators) group, and a few highly privileged global groups such as stewards, can edit CSS/JS pages that they do not own (that is, any page ending with .css or .js that is either in the MediaWiki: namespace or is another user's user subpage). This is done to improve the security of readers and editors of Wikimedia projects. More information is available at Creation of separate user group for editing sitewide CSS/JS. If you encounter any unexpected problems, please contact me or file a bug.

Thanks!
Tgr (talk) 12:39, 27 August 2018 (UTC) (via global message delivery)

Read-only mode for up to an hour on 12 September and 10 OctoberEdit

13:33, 6 September 2018 (UTC)

MediaWiki:Print.css hides the TOCEdit

Since 2010 we hide the table of contents into the print versions. However in the printed paper books, the tradition is to publish it, and I think it wouldn't hurt here.

For example we can compare the followings:

JackPotte (discusscontribs) 18:22, 16 September 2018 (UTC)

I've never been much involved in print-version stuff, but wonder if anyone else who was involved at the time can shed light on why it was done. Darklama who made that edit appears to have had no wikimedia activity since 2014; but Adrignola, who was the other primarily involved in setting up the page, is still extant on the sisterhood as of this year. --Pi zero (discusscontribs) 19:03, 16 September 2018 (UTC)
I don't mind either, though I should note that the TOC for a print book can become very large and itself occupy many pages. Also the main purpose of a TOC isn't served; there is no page numbers for which a user can go to (and the titles itself aren't even clickable), so in the end it serves no purpose. Leaderboard (discusscontribs) 20:11, 16 September 2018 (UTC)
This seems an awkward in-between sort of thing. Most books here have a table of contents built into the content, but most of those are on the book main page which afaik is not usually included in the print version. --Pi zero (discusscontribs) 21:40, 16 September 2018 (UTC)

The GFDL license on CommonsEdit

18:11, 20 September 2018 (UTC)

Clean up on Talk:Drugs:Fact_and_Fiction#Cleanup_listEdit

I've proposed a clean up on Drugs:Fact and Fiction. It's been up since 9/10/2018. I already know because of how much I want to clear away , this would be a controversial action. Rather than just simply be bold and do it, I left a detailed message of what I want to remove and why. I'd plan to start cleaning if there were no objections as of today, however, since only myself and Leaderboard had commented, I thought it wise to hold off and see if we can get more comments on this topic. Feel free to comment over here. I've tried to avoid TL:DR by breaking my list into separate sections, rather than create one large list. Necromonger Wekeepwhatwekill 14:22, 24 September 2018 (UTC)