Wikibooks:Reading room/Proposals

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

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


Echo and watchlist[edit]

Special:Notifications & Special:Watchlist substantially overlap in functionality, except the former also contains extra (some non-public) events and doesn't provide with passive usage options (means to turn off web-nagging or email-nagging and to just keep visiting the page whenever I'm free), while the latter doesn't provide with options of active web-nagging notifications (but already provides email interface). Partly, in my personal view, the Echo/Notifications project was driven by low usability of watchlist; [1] comes to mind. It's also perhaps worth noting that Echo users aren't exposed to Special:Notifications unless thy have JavaScript disabled — in which case it's their only means of reading the notifications.

I'd like to get this done:

  1. Merge these two pages into one.
  2. To remedy large inflow of information, introduce multiple levels of importance of the web-nagging notifications (red for mentions, orange for thanks, blue for new watchlist items, etc and configurable in your settings).

Thoughts on both, please? --Gryllida 02:19, 9 September 2014 (UTC)

Nice idea, although you're more likely to generate interest discussing this on Meta or MediaWiki where these issues are generally pushed around... QuiteUnusual (discusscontribs) 07:25, 9 September 2014 (UTC)
Merging the two into one could make both more complex and thus less useful. I rather like both the way they are, as I perceive them as serving different purposes — notifications for a small number of personal items, watchlist for a bigger picture of mostly-less-personal items.
Which said, I still don't understand what Echo is; I've tried to find information about it, but half the time, pages say it's the same as notifications, while the other half, they talk about it as something different but evidently assume everyone already knows what. --Pi zero (discusscontribs) 10:13, 9 September 2014 (UTC)
Echo and Notifications are indeed the same thing (see mw:Echo (Notifications) QuiteUnusual (discusscontribs) 11:29, 9 September 2014 (UTC)

Discouraging class projects[edit]

I'm pretty sure this is a controversial proposal and very unlikely to get much agreement but I'd like to discourage / restrict or prevent class projects. I'm unsure about when they started becoming popular but they seem to have proliferated in the past two years. What do they bring to the project? (me: nothing) How many of their contributors contribute elsewhere in Wikibooks or stay behind after their class project is over? (me: unsure, I imagine very, very few) Does anybody ever edit or read their books once they're gone? (me: read - unsure, edit - few) Do they bring down the tone and quality of the project? (me: I believe the quality of the work is often very poor and riddled with grammatical and spelling mistakes) Unless some effective way of managing them is brought in then I'd say they shouldn't be allowed on Wikibooks. Constantly patrolling their pages, fixing some atrocious grammar and encouraging people to read up about the project, policies, etc. is tiring. I'd support either a mandatory registration for the project where they are required to register user names and a person responsible for the project and a declaration that they are familiar with how things work - or - not allowing class projects. This may seem like snobbery or some anti-newbie feeling but I don't see what they contribute. Somebody who drops by just by chance and reads the content of many of those books is unlikely to stick around or form a positive opinion of Wikibooks or Wikimedia. --ЗAНИA Flag of the Isle of Mann.svgtalk 20:32, 30 November 2014 (UTC)

Could you suggest some examples to look at? And, have you discussed this with instructors involved in such things?
Use of en.wn as part of class work has been a good thing for en.wn, and for the students, I think, but of course en.wn has a vigorous review system that has to be passed and that's part of what the students are sent to us for. I've heard (I thought) good things about students being sent to contribute to en.wp, too. It seems quite important to understand why it wouldn't work as well for en.wb, and what can be done to make it work better here. --Pi zero (discusscontribs) 03:04, 1 December 2014 (UTC)
"a mandatory registration for the project where they are required to register user names and a person responsible for the project and a declaration that they are familiar with how things work" - I strongly support his option rather than a ban on class projects. Let's not throw out the baby with the bathwater. At the EduWiki Conference recently we were discussing how Wikibooks is a welcoming project for student assignments; more welcoming than Wikiversity or Wikipedia. Better preparation by the course leaders, a focus on genuinely useful content, and more feedback from the existing editors: all these would help the educational goals of the projects as well as create fewer headaches for us on Wikibooks. Having to tidy up the formatting is not a problem, so long as the content is valuable. I'd rather create a set of good Wikibooks by tweaking the formatting on lots of other people's work than trying to write them all myself. MartinPoulter (discusscontribs) 20:43, 1 December 2014 (UTC)
When I was less busy in real life I spent more time on cleaning up the mess, adding templates, advising contributors, etc. - but it takes a huge effort. The students are in general massively unresponsive to simple instructions or feedback. More editors willing to help guide the participants would help. The current mess being created with the big active class project is horrible. It is too active for me to bother getting involved - once they are gone I will clean it up. QuiteUnusual (discusscontribs) 21:49, 1 December 2014 (UTC)
I think most of us think that a ban is too much. I think the same I guess and I threw the idea about to encourage some discussion. I think the way to go is a policy whereby on seeing what looks like a class project, all editors concerned are directed to a page requiring them to register, nominate a person in charge and confirm that they have read up on policies, rules, etc. This could be a firm requirement. In my view Wikibooks is more helpful than Wikipedia but I don't know if we're more welcoming (nor do I want to be). We spend a lot of time guiding and coaching new users. Additionally I think the class projects do create endless headaches regarding formatting (page titles, templates, endless typos, appalling grammar) and there are too few active people here to sort it all out. We have a huge amount of books and so many of them are abandoned, rarely read and some of them are, quite frankly, shit. That's my rant over. I think the next step would be some kind of class project policy incorporating some of these ideas. I quite like the idea of a different namespace (is that the right word?) for such projects like Wikijunior and Cookbook have so they would be easier to manage - we could set the namespace to only show approved edits, for example. Any comments about this?--ЗAНИA Flag of the Isle of Mann.svgtalk 23:46, 1 December 2014 (UTC)
I agree. Perhaps it might be useful to make it a requirement that class projects (and their books) are 'flagged' as such after going through the registration process you've mentioned - maybe a registration process could even be advertised to some extent. Anything created that's associated with the project could then be hidden from search results and/or hidden from changelogs. Additionally, the accounts associated could have their edits on other pages/books restricted some way (either by making their edits require explicit approval from someone outside the project or by blocking edits completely). After they're done doing their thing, after a specified period of inactivity (90 days or when the elected coordinator declares the project inactive, whichever is sooner) the entire thing gets deleted (accounts also? Maybe they could just be 'released' as a regular account). Personally, I think class projects should just be banned altogether, but this is probably a more 'humane' way of dealing with them ;) --SporkSauce (discuss

contribs) 10:45, 15 December 2014 (UTC)

Here , keeping strict registration requirements for class projects is not a good idea. First , the books themselves could turn to be useful. Requiring explict approval on other books is unfair , because some of the editors may have an interest to edit other books and take a liking to Wikibooks. We're just killing them out when we impose these restrictions(like we're sayiing "You have an Wikibooks account only to edit this book which will be soon deleted.") We could instead keep a watch on the books and maybe nominate a responsibe person , but anything more is not good. Anynomous edits should be allowed(unless it is used for bad things) , even for class projects , because they may also want to improve the project.

Or , we could create a separate controlled registration-only category for class projects and then either archive the book or integrate the book into the mainspace when it's finished depending on the work and quality of the book. Accounts won't have any registration and can even get reviewer status etc.?

--Leaderboard 12:49, 15 December 2014 (UTC)

The process of converting classic talk pages to Flow[edit]

(BG: Flow). There are various ways to convert talk pages to Flow. Discussed at this page. I would like to know what we would like to have. Please join the discussion and spread it to other language village pumps. Gryllida 00:00, 12 December 2014 (UTC)

Flow must not be allowed to happen. Imposing it would be fatal. --Pi zero (discusscontribs) 00:52, 12 December 2014 (UTC)

Ban user page editing for IP users[edit]

I think it is a good idea to disallow user page(not talk) editing to IP users(or anyone except the user himself) because

  1. User pages are frequently vandalised easily by anynomous users(this's happened to me).
  2. The user himself should edit his page , why should someone else do it?

--Leaderboard 13:43, 15 December 2014 (UTC)

Would that apply to an IP editing their own user page? --Pi zero (discusscontribs) 15:53, 15 December 2014 (UTC)
Maybe not then. As I said , my idea is to prevent anymomous users from editing other user pages. Anynomous users can edit their own pages , but not anyone else's.--Leaderboard 17:09, 15 December 2014 (UTC)
Symbol support vote.svg Support I'm sick and tired of IP spam. Can't see any problem with this idea so long as an IP would still be able to edit their own page. It might encourage more people to remember to log in and it's better for everybody because there are so many privacy issues associated with IP editing. I presume that the original poster meant IP users when he said anonymous users??? In my opinion an IP user is anything BUT anonymous.--ЗAНИA Flag of the Isle of Mann.svgtalk 23:23, 17 December 2014 (UTC)
Yes , I meant IP users. I meant anonymous users as users who are not logged in.--Leaderboard 11:53, 18 December 2014 (UTC)
Well, IP editors don't in my opinion have their own user page anyway - so blocking that as well would be fine. Remember most IPs are dynamic, so the IP user page doesn't "belong" to anyone. It is super easy to do with an edit filter. QuiteUnusual (discusscontribs) 17:25, 18 December 2014 (UTC)

Customization to Common.js[edit]

I'd like to add a one-executable-line snippet to our (admirably short and simple) Common.js. This takes a bit of explaining, I guess.

My intent is to enable a particular kind of site customization: page-specific javascript — allowing admins to customize any page on the wiki with a javascript file to be executed whenever that page is loaded. This is javascript by page rather than by user; even IPs get the benefit, since Common.js applies to them too. En.wn has had page-specific javascript for many years. Although it can be used to customize the appearance of a particular page (en.wn does this for a few pages), it's particularly useful for setting up a particular page as a "verb" (rather than a "noun"). There should be no observable performance penalty from this facility, for any page that doesn't get customized with page-specific javascript.

My central interest in this type of customization is that it is the first step to porting my interactive dialog tools here from en.wn. I believe the dialog tools, and particularly the wizard-like semi-automated assistants that can be built from them, could over time become a major asset to Wikibooks (and to Wikinews, of course, which is why I've undertaken the development of the dialog tools there). I've tried to summarize the full process of porting the dialog tools here (though I expect eventually I'll be moving that page, since its page name is actually one of the things that ought to be changed for project-generality).

The actual technical addition would be the following, just below the book-specific block.

// Page specific
importScript( 'MediaWiki:Common.js/w/' + mw.config.get( 'wgPageName' ) );

This would be executed when any user (even an IP) loads any page (even a Special: page). When loading wiki page PAGENAME, it checks for existence of a page called MediaWiki:Common.js/w/PAGENAME, and if there is such a page, loads it as a javascript file. The customization is limited to admins, since the customizing page is in MediaWiki: space. --Pi zero (discusscontribs) 21:07, 17 December 2014 (UTC)

fine by me, but beware the WMF staffers who sometimes don't like us mere mortals customising the interface in "inappropriate" ways. QuiteUnusual (discusscontribs) 17:27, 18 December 2014 (UTC)
We cannot control bad decisions by the WMF. We can make competent decisions, ourselves. If our competent decisions are successful and gain momentum, there's some chance the WMF might recognize the need to take them into account. If we hold back from making competent decisions, in mere anticipation of contradictory bad decisions by the WMF, we guarantee that eventually the WMF will make bad decisions with impunity.

I have been told, in the past, that my dialog tools shouldn't conflict with VisualEditor (should we have the misfortune to have that inflicted on us at some point). --Pi zero (discusscontribs) 18:13, 18 December 2014 (UTC)