Wikibooks:Reading room/Proposals/2012/May

User group analysis
Since the earlier thread was sidetracked into a discussion of changes to flagged revisions autopromotion criteria for the reviewer group, I'd like to focus a discussion on the merit of existing groups and whether or not they are appropriate for Wikibooks. Please preface comments with "remove" or "keep" to prevent confusion. Given that two of the groups cannot currently be granted by admins, keep positions should be assumed to indicate a desire to alter the configuration so that they can be assigned unless stated otherwise. – Adrignola discuss 13:17, 30 April 2012 (UTC)

Account creators

 * Not be affected by rate limits (noratelimit)

Account creators are not affected by the 6 account creation limit per day per IP, and can create accounts for other users without restriction. Users in this group can also override the anti-spoof checks on account creation. Cannot currently be assigned by administrators. – Adrignola discuss 13:17, 30 April 2012 (UTC)


 * Remove. We don't really need the account creators group when it's rolled into the administrators group and we don't commonly have a backlog of people needing to create accounts from soft-blocked IPs (or any requests, really). – Adrignola discuss 13:17, 30 April 2012 (UTC)
 * Remove. I've had one request for help on this for a class project in two years - and even then it was only ten accounts. I don't recall any account request for a soft-blocked IP. QU TalkQu 15:08, 30 April 2012 (UTC)
 * Remove. No call for the complication of a separate group for this.  --Pi zero (discuss • contribs) 15:57, 30 April 2012 (UTC)
 * Remove. KISS, we are not really getting anything out of having such a group on this wiki. Thenub314 (talk) 16:23, 30 April 2012 (UTC)
 * Remove. I think the average person only needs 1 account. Administrators should be able to address any unusual need for additional accounts. --dark lama  17:11, 30 April 2012 (UTC)
 * Remove. Per above  Liam987  07:40, 1 May 2012 (UTC)
 * Remove - I'm an account creator at enwp, and some folks developed a really cool system, if somebody needs help, we still can redirect them to w:en:WP:ACC. mabdul 01:09, 22 May 2012 (UTC)

Confirmed users

 * Edit semi-protected pages (autoconfirmed)
 * Move pages (move)
 * Move pages with stable versions (movestable)
 * Perform CAPTCHA-triggering actions without having to go through the CAPTCHA (skipcaptcha)
 * Save books as community page (collectionsaveascommunitypage)
 * Save books as user page (collectionsaveasuserpage)

Theoretically could be granted by administrators if users couldn't meet the requirement for autoconfirmation (four day old account) but is not yet in the list of rights that admins can grant. Lacks the abusefilter-view and abusefilter-log rights assigned to autoconfirmed users (this could be changed). – Adrignola discuss 13:17, 30 April 2012 (UTC)


 * Remove. Why have confirmed users when autoconfirmation simply requires waiting four days and the group lacks two permissions belonging to autoconfirmed?  If we decided at some point to put an edit requirement on autoconfirmed, then the confirmed users group might make sense. – Adrignola discuss 13:17, 30 April 2012 (UTC)
 * Remove. Unnecessary. Where this exists on the English WP approximately 90% of the requests are rejected, so it would add little / nothing here. QU TalkQu 15:08, 30 April 2012 (UTC)
 * Remove. Seems a needless complication to our infrastructure.  --Pi zero (discuss • contribs) 15:57, 30 April 2012 (UTC)
 * Remove. I can't really add much to what is already said, other than I think it should also be removed.  Thenub314 (talk) 16:49, 30 April 2012 (UTC)
 * Remove. 4 days is a short waiting period. I could understand having this group if auto confirmation required waiting 30 days or having a few thousand edits. --dark lama  17:11, 30 April 2012 (UTC)
 * Keep. There are conceivable situations where this would be useful. If someone switched accounts because there account was hacked, or something like that.  Liam987  07:45, 1 May 2012 (UTC)
 * Take a look into the Autoconfirmed users group in Special:ListGroupRights. It could have a use in the future, but as those defending the removal state, not now. For instance if we ever use CAPTCHAS (or another reason, like the one Adrignola pointed out) it could serve to segregate those that the admiship validated as confirmed and those that were automatically validated by the system. --Panic (discuss • contribs) 08:05, 1 May 2012 (UTC)
 * Wikibooks has no community approved process to address claims about lost or hacked accounts. I suspect most Administrators would err on the side of caution by taking no action and suggest the person needs to prove themselves all over again through their contributions and participation under the new account before they can receive any groups. The other account probably wouldn't be blocked or have any groups removed either, unless or until any actions from that account are inappropriate. --dark lama  12:06, 1 May 2012 (UTC)
 * Committed identity is the closest to a "formal" process but that is more to do with regaining control of a hacked account. <font color="#E66C2C">QU <font color="#306754">TalkQu 12:46, 1 May 2012 (UTC)
 * Conceivably requests for permission on the bases of lost or hack accounts may be rejected, and the use of committed identity may allow a person to regain a lost or hacked account which would avoid the need to make a request for permission. Either way the confirmed group may not be useful under the situations conceived by Liam987. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  15:46, 1 May 2012 (UTC)
 * Just a question: Can the autoconfirmed right be manually added?  Liam987  07:33, 4 May 2012 (UTC)
 * As I understand it, no and that's why the Confirmed user group exists for us to be discussing. Unless I've missed something, of course. :-)  --Pi zero (discuss • contribs) 10:27, 4 May 2012 (UTC)
 * Yes, thats what I thought. In that case, I think this group might be useful to have around, in case we need it. No good enough reason to delete it.  Liam987  16:18, 4 May 2012 (UTC)


 * Remove - waiting four days without doing anything and getting the right? We can remove then the right also! <small style="font: 12px Courier New;display:inline;border:#009 1px dashed;padding:1px 6px 2px 7px;white-space:nowrap"><font color="#000">mabdul 01:13, 22 May 2012 (UTC)

Autoreviewed users

 * Have one's own edits automatically marked as "reviewed" (autoreview)

This group was added without community consensus as part of routine upgrades to the software. While Wikipedia, when it used pending revisions, required all reviewers to have the flag explicitly added, we have certain autopromotion criteria that adds individuals to the reviewers group. This group has its own edits automatically reviewed, while reviewers have that but can also review others' edits. This section is focused on whether the group should even exist and not if/when we should hand it out, so keep that in mind. – Adrignola discuss 13:17, 30 April 2012 (UTC)


 * Keep and define criteria for assigning it to users (no details here - for a separate thread) <font color="#E66C2C">QU <font color="#306754">TalkQu 15:08, 30 April 2012 (UTC)
 * Remove. I appreciate the point that this is about whether it should exist as opposed to when it should be handed out &mdash; but keep in mind that saying the group shouldn't exist is exactly the same as saying it should never be handed out.  And that is essentially my position:  if a person shouldn't have the reviewer right, they shouldn't have the autoreview right.  There is a problem that wants addressing, namely that people who don't have the reviewer right shouldn't be harassed about their edits having not yet been reviewed.  --Pi zero (discuss • contribs) 15:57, 30 April 2012 (UTC)
 * Remove. I agree that users who are not reviewers should not get their edits autoreviewed.  Philosophically, reviewers shouldn't even have that option, but there is not enough man power to support such a philosophy.  So it seems to me we should make people wait until they are trusted to review others edits before they themselves can have their edits go by without review. Thenub314 (talk) 16:52, 30 April 2012 (UTC)
 * Ah, philosophy! I guess it depends on why you (we) think the "review" function is there in the first place. If it is an anti-vandalism tool, or a quality assurance tool, might make a difference to whether it is right (or wrong) to enable autoreview (or not)...! I think here it is primarily being used as an anti-vandalism tool and once a user is trusted not to vandalise is a different point to when they are trusted to confirm someone else isn't vandalising. If it is a QA tool, well, that's different. Philosophy is not my strong point though! <font color="#E66C2C">QU <font color="#306754">TalkQu 17:16, 30 April 2012 (UTC)
 * Remove. When would people believe in a person's ability to make good edits, but not in a person's ability to make good reviews? Also, I thought the community had previously decided that no edits should be auto reviewed to avoid problems it can cause, which would make this useless in that respect as well. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  17:11, 30 April 2012 (UTC)
 * Keep and define criteria for assigning it.
 * autoreview right is distinct from reviewer right.
 * autoreview right is a simple way of addressing pending reviews from safe editors.
 * not all wikibookians are autoconfirmed as to have reviewer right.
 * autoreview is not about page quality, but about reducing the review function impact and ease review work.
 * I so far see no argument explaining why keeping it would be a problem or at least undesirable. Most, if not all, of the objections are too generalized to be addressed or make considerations outside of what is under discussion. --Panic (discuss • contribs) 19:36, 30 April 2012 (UTC)
 * I so far see no argument explaining what problem is addressed by keeping it that isn't addressed by requesting permission for reviewer. A simple way of addressing pending reviews from safe editors who are not autoconfirmed is to add them to the reviewer group. Review work is eased more by allowing safe editors to review edits in addition to having their edits reviewed automatically, which is achieved by the reviewer group. Another user group is undesired because there is no clear advantage to it over the reviewer group. The community also agreed previously to remove another group related to editor reviews because it caused confusion and extra requests for permission for groups that weren't required to achieve what the requester wanted. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  20:06, 30 April 2012 (UTC)
 * You partially answer your own question. Autoreview right will address jumping the auto-promotion and adminship intervention on the processes (I would be less concerned in administrator jumping the line based on their judgment for Autoreview right than Reviewer rights). I have issues in granting review power to a non-autoconfirmed user, one may need to contact the user to address some review and having an email also increases accountability, the user also is limited in the use of the roll back function. --Panic (discuss • contribs) 20:16, 30 April 2012 (UTC)


 * Keep.  Liam987  07:47, 1 May 2012 (UTC)
 * Keep per QU. (and discuss if we existing ones should get removed) <small style="font: 12px Courier New;display:inline;border:#009 1px dashed;padding:1px 6px 2px 7px;white-space:nowrap"><font color="#000">mabdul 14:35, 22 May 2012 (UTC)

Reader Feedback -> Article Feedback
The extension Reader Feedback seems to not be working. Even worse it is marked as obsolete. The successor to Reader Feedback is an extension known as Article Feedback, keeping the same configuration. It seems sensible to ask the wikimedia folks to upgrade WB to the successor before trying to diagnose the problems with the first and finding out they can't be fixed because the package is obsolete.

I also wanted to point out that Article feedback is already in use at english wikipedia. So the sysadmins shouldn't have too many objections to is use. This would involve installing several other "helper" extensions, but hopefully this won't causes any snafu's.

I propose we upgrade and keep the same configuration. Thenub314 (talk) 04:41, 26 April 2012 (UTC)


 * Isn't that extension intended for Wikipedia single page articles (Will it work fit our multi-page works in a meaningful way)? Will the standing quality criteria and levels be maintained?
 * I've never been a supporter of the review function as a edit qualification tool, only as a edit validation tool (those functions are distinct), I strictly review in the lowest setting and rarely have I encountered pages reviewed at a higher one.
 * Aft phase 2.jpg
 * To me it seems to go beyond what we intended with the ReaderFeedback and I can see if implemented in subpages as detracting people to work on the content or provide a better description of the page's faults in the talk page (Well I'm also a chronic discontent in having multiple talk pages in what are single works). This would again increase fragmentation of the editors/readers opinions.
 * Was it removed from Wikipedia, I do remember seeing it active there... --Panic (discuss • contribs) 05:41, 26 April 2012 (UTC)
 * Reader Feedback wouldn't be any better designed to cover a book as a whole rather than a single page. Therefore Article Feedback (don't be misled by the name) would simply be a drop-in replacement.  I doubt feedback would transfer over, but there aren't many pages that have gotten enough ratings in the first place to have feedback that the current extension will display.  (Certain thresholds have to be met in terms of number of ratings).  Just like the current extension, this is for readers, not editors, and is not a substitute for flagged/pending revisions. – Adrignola discuss 12:45, 26 April 2012 (UTC)
 * It seems to me that feedback on pages/chapters (or whatever term you want to use for bits of a book) may be more useful than feedback on a whole book. I think most editors have one to a few books that they work on, and if within that there are pages that are felt by the readers to behind the rest of the book, that's somewhere where we can concentrate effort, especially as the typical reader would know less about the subject than the typical editor.  If a whole book needs work, that seems to me to be quite obvious. ChrisHodgesUK (discuss • contribs) 16:08, 26 April 2012 (UTC)


 * That would imply a change to the current function that is not intended to evaluate intrinsic content quality except on the higher setting Help:Tracking changes that is rarely used. The tool is used as a our primary counter-vandalism tool.
 * Note that reviews will still be a domain of the Wikibookians on the Reviewers group not open to all.
 * I still think that dialog is better than a quick click to access content quality and direct changes, and that using a tool that will redirect the instinct to do a proper comment/criticism or even do the correction itself will not be beneficial. --Panic (discuss • contribs) 16:19, 26 April 2012 (UTC)
 * I'm sure that's all true, I had in mind capturing feedback from readers who aren't well placed to contribute (through lack of knowledge/time/inclination) - the talk page is always appropriate of course, but a way to rate a page might help with less specific issues. At most though, it's a nice-to-have, and easy enough to ignore.  ChrisHodgesUK (discuss • contribs) 15:22, 27 April 2012 (UTC)
 * I agree for the general book project, not in a per page setup (it can even be demoralizing). Note also that the function is mostly anonymous the qualifier is not responsible, not even for using the tool correctly, it is also open to difficult to detect bot action.
 * But as I said that would require changing how the tool was setup and permit access to the qualification to the general Wikibookian, that is not what is under discussion now. --Panic (discuss • contribs) 16:38, 27 April 2012 (UTC)


 * You say it will be a drop in but I don't see the way the options provided that are rated in degrees can be adapted to our sparser version.
 * If I remember correctly one point that also became relevant in the adoption of Reviews was visibility profile, the visual impact. This new extension seems to require more space and call more attention (design wise).
 * This in regards to the notion of it being a "simple" replacement. I would indeed like to see an extension designed for Wikibooks something like this but for the complete book and as a substitute for the Featured process, but I'm inclined to oppose the the upgrade, still waiting for augments for it. Note that I have been critical of the Reader Feedback extension (that has been useful as an anti-vandalism tool).  --Panic (discuss • contribs) 16:39, 26 April 2012 (UTC)


 * It seems the Reader and Article Feedback extensions are being confused for the FlaggedRevs extension. FlaggedRevs provides the editor (reviewer) group, stable pages, quality is judged by editors, the quality ratings do not accumulate, and pages are flagged as free from vandalism. Reader and Article Feedback provides a way for readers to judge the quality of pages, quality ratings do accumulate, and there is no page stability involved. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  17:22, 26 April 2012 (UTC)


 * Yes it was. Will contact the Wikibookian, to make my error clear. --Panic (discuss • contribs) 22:26, 27 April 2012 (UTC)


 * That seems in line with what Pi zero states below, that they are essentially connected here... --Panic (discuss • contribs) 17:44, 26 April 2012 (UTC)


 * I said they are unrelated to each other, which is the opposite of what you appear to be claiming I said. I do agree that what Darklama says here is in line with my statement that they are unrelated to each other.  --Pi zero (discuss • contribs) 19:29, 27 April 2012 (UTC)
 * Agreed, they are separate issues and we should try to keep them that way.  The only thing I wish to propose is: "We should upgrade. The current system is broken, it is marked as obsolete, so it is not getting fixed." Thenub314 (talk) 19:50, 27 April 2012 (UTC)


 * This connectivity is how I took the previous discussion and decision that you referred below as a "bundled activation". Doesn't the last two options of the FlaggedRevs to some degree overlap the function of ReaderFeedback options ? (At some point I did confuse the two functions of the extensions, I hope I've fully corrected that now). --Panic (discuss • contribs) 22:35, 27 April 2012 (UTC)


 * Is the feedback (whichever extension) useful? Are there drawbacks to having it at all?
 * Background: I seem to recall we bundled activating feedback along with the last big reconfiguration of flaggedrevs, even though they're really unrelated, because we thought it'd be more convenient for the devs to change a lot of things at once (we were later told otherwise). There was as I recall some objection to bundling them together, and not everyone wanted the feedback extension.
 * --Pi zero (discuss • contribs) 14:05, 26 April 2012 (UTC)


 * My view is that we keep adopting stuff that is not designed for Wikibooks purposes, like a younger brother that gets pass-me-down clothes, they rarely scratch the itch we have. I've been looking to previous discussions and it is clear that there have been very few benefits for having these new toys to play around, it only serves to add complexity and extend processes. I noticed that there was at least one previous call for the removal of the FlaggedRevs if the function is causing problems I'm more inclined to dropping it that adopting yet another more complex variation. KISS rule should always be considered... --Panic (discuss • contribs) 17:50, 26 April 2012 (UTC)


 * This thread is totally unrelated to flaggedrevs. Kindly do not attempt to highjack it to serve your obsession therewith.  --Pi zero (discuss • contribs) 19:29, 27 April 2012 (UTC)


 * Just making it clear that I agree with your statement regarding that "we bundled activating feedback along with the last big reconfiguration of flaggedrevs" and that "There was ... some objection to bundling them together", and remembering also that the flaggedrevs itself has been criticized.
 * The first mention of support to Reader Feedback, I have found (chronologically) after WK exposition was Darklama's view that it could address the topic of featured works. To what I fully agree but not on a per page base (in that I share most of the negative impact concerns expressed on meta regarding the extension). But most of this was already discussed when we decided on the ratings. --Panic (discuss • contribs) 21:59, 27 April 2012 (UTC)


 * Well, in my opinion the main drawback is some visual clutter at the end of every page (which as it stands is already present, but is configured to be less obtrusive then the image given above). Getting feedback from readers about which parts of a book are good and which parts are bad might be helpful to editors trying to improve books, as it tells you where improvement is needed most.  Your memory is very good, and I was one of the main opponents to the extension.  But regardless of how I feel about it, keeping a broken obsolete version in place doesn't make any sense.  So we should either deep six the existing extension or upgrade.   But to focus my answer on your question, I do think it is useful, but the real question is: is it useful enough to justify the space at the bottom of the page?  For the moment I am willing to keep trying it out, particularly if we get it working.  But mostly I am skeptical.  Thenub314 (talk) 19:47, 27 April 2012 (UTC)


 * You may add  to your common.css to hide the current extension. – Adrignola discuss 01:05, 28 April 2012 (UTC)

As to reach a conclusion about this discussion. I hereby call a check to see if we got consensus regarding the proposal as presented. Please take in consideration what has been previously said on the subject. This process will be open for participation until 7 days after the last post on this thread. No opposition (or its restatement) will mean that the upgrade as proposed will be implemented. --Panic (discuss • contribs) 00:28, 12 May 2012 (UTC)
 * reset ident
 * Panic, you like to define your version of reality to be consensus reality. "No opposition (or its restatement) will mean that the upgrade as proposed will be implemented" &mdash; &lt;expletive deleted&gt;.  You don't run the project.  Time you gave up the delusion that you do.  I actually like you, and appreciate the many positive contributions you make to the project, but you're one of the last people I'd trust to judge any consensus.  --Pi zero (discuss • contribs) 03:33, 12 May 2012 (UTC)


 * I have no delusion that I run the project and I find it strange that you continue to see pro-actively seeking resolution to pending issues as me dictating anything. Something that if you were not asleep would fully understand that I abhor such type of insinuations. I never claimed anything that would transmit that notion, just to the contrary.
 * Since you also do not run the project, I do not see what impact or productive contribution your above post makes to the topic under discussion. If you have something constructive to state go ahead, if not please discontinue your disruption here.
 * By the simple definition of a state of non-objection consensus will be self evident without a need for anyone to pass judgment. I am still waiting to see how the discussion, of the previous aborted process, will end. Who will call the outcome a consensual decision (or find it lacking it) based in an active participated discussion where facts and arguments, more that numbers or power to enforce control are used to validate said conclusion.  --Panic (discuss • contribs) 04:51, 12 May 2012 (UTC)


 * You are actively seeking to cause things to happen by high-handedly pronouncing the default (if nobody says anything) to be taking that action. It should be obvious that this is nonsense; in a situation where there isn't support for doing something, it's a no-brainer that nothing is done.
 * You are trying to dictate "rules" of discussion to create an appearance of consensus for action out of nothing. It is, unfortunately, not safe to allow such tactics to go unchallenged, as sooner or later someone with authority to act might be misled into action by them.  --Pi zero (discuss • contribs) 12:15, 12 May 2012 (UTC)


 * It is sad that we are using this thread to discuss something that goes beyond its topic but for the sake of being complete and provide a response that everyone can read this is the second time you have covertly accused me of being using some sort of bad practice. That is simply BS and I have previously pointed to you that it is in fact normal practice.
 * Even if several modalities may exist, this one is my favorite as it clearly indicates that a discussion is not a vote and avoids unnecessary participation for agreement to a proposal focusing in attempting to remove blocks (that are in fact why discussions occur). If you took sometime to examine past practices and best outcomes, even if solely in a conceptual way you would at least see that. Consider that each proposal has a proponent (except for RfD, that has a specifically established discussion process) all proponents are viewed as in support for the motion they advance. In a system that can not guarantee participation nor force it I do not see how you are stating that a proposal needs more than the initial proponent to be considered valid. I would consider arguments as to support the requirement for a second on motions (especially for the closing of discussion) but ultimately it would only serve the purpose of avoiding meritless processes something that we rarely see and on the other hand would exacerbate processual errors...
 * One other benefit is to have a clearly expressed end term added to the discussion process (that is itself open to alteration). I find it gravely annoying that proposals and discussion processes are at times archived without a conclusion.
 * Unless you can provide arguments that non participation, the default (if nobody says anything) is an acceptable reason to block a proponent. As it escapes me, I do not see any negative side. Considering that we should be well intentioned (even if with individual shortcomings) any objectionable decision even if past approval date could be motioned for readdressing. We do not have time limitations between contrary proposals and all decisions are open to change at any time. What it does is more the burden to justify the action to those that did not participate on the first, nothing more.
 * In fact you are being more than unfair to me in how you portray the issue, you know perfectly well that as a non administrator I more than most every one that participates in discussions have not even the power to enforce almost any actions. So think a bit when you try to paint me as a dictator or abuser and look around, I'm certain that you would find better examples to correct...
 * This time there is no ethical issues or special consideration to be given to you. I'm not aborting the process as I see no merit on your arguments so far. Every Wikibookian can, and some have, used equal methodology. Once again it is sad that this talk was included on the thread.
 * As to provide something on topic and clear any wrong perceptions. I do not support the proposal but I've chosen not to block, I have expressed my concerns above but ultimately agree with the information provided (if the impact can be greater there is a way to hide it). My choice would be the removal of the extension but that was not the proposal or shown as a possible outcome during the discussion. --Panic (discuss • contribs) 13:37, 12 May 2012 (UTC)
 * You have previously asserted that what you are doing in these cases is common practice. Note the difference between "pointing out" and "asserting" &mdash; these discussions often end when you make an assertion that I find strikingly unsupported by, or even contrary to, empirical evidence, and I despair of getting through to you so I simply stop responding.  It seems likely you misinterpret these silences as your having "won"; that's why I'm not simply being silent now, but my non-silence will presumably have a different sort of undesirable consequence, and it seems likely I'll soon despair again and stop responding.  --Pi zero (discuss • contribs) 14:19, 12 May 2012 (UTC)
 * Not exactly, regardless of it being "pointing out" or "asserting", when an argument is made if there is no reply the normal assumption is that it was accepted or as you state not worth arguing about, at best inconclusive. Much like the process of discussion you are arguing about. In that particular case I did not assume victory since victory requires stated acknowledgment and that was specifically what I was after in the first place, as stated. --Panic (discuss • contribs) 14:37, 12 May 2012 (UTC)

Positions

 * I personally hide the feedback extension and I feel it should be removed due to the fact that any particular page will not get enough views, much less [reader] reviews to make any feedback received from either the current or new extension accurate or worthwhile. Even the main page doesn't get enough to create a graph under the current extension.  Better to encourage personal feedback in some forum dedicated to the purpose. – Adrignola discuss 12:17, 12 May 2012 (UTC)


 * The upgrade would make it more distracting that it is (I do not hide it at present but will if the upgrade has the visual impact I'm expecting). I have only used the extension on the first day it was activated and on the works I edit. I also agree with almost all the negative appreciations made on the extension talkpage. It moves the momentum from active participation to one of a perceived useful qualification, that will have even a lesser effect that a negative critique on a talk page. Adds necessary complexity without fully catering to Wikibooks needs (a similar extension but encompassing each project - not each page - would be extremely attractive especially as a substitute to the process we have now to select featured books). --Panic (discuss • contribs) 13:59, 12 May 2012 (UTC)
 * Would it be possible to use JavaScript to block this extension (or preferably the upgrade) on subpages?  Liam987  15:22, 23 May 2012 (UTC)
 * removed indent and added two stars instead Do you mean activating the extension for all books and then redo it for sub pages? I think it is more useful/easier to either change the extension itself or to use a w:CSS hack for that. Moreover is JS bad ^^ - for example (this is escpecially for readers important) isn't JS supported on many mobiles, screenreaders (for blind readers) or limited browser like Lynx. <small style="font: 12px Courier New;display:inline;border:#009 1px dashed;padding:1px 6px 2px 7px;white-space:nowrap"><font color="#000">mabdul 22:35, 24 May 2012 (UTC)


 * Although I'd be interested to hear a case made in favor of this extension, myself I don't see it. It seems a distraction that doesn't accomplish anything useful, and detracts from the more articulate feedback function of talk pages.  --Pi zero (discuss • contribs) 14:27, 12 May 2012 (UTC)


 * Remove per Adrignola, however I agree with Panic that a book-level version would be great.  Liam987  13:32, 22 May 2012 (UTC)


 * Remove the extension until a better (more suitable for Wikibooks) is created. I highly doubt that any developer will invest some work in such an extension, moreover I'm regular chatting with en:User:Ironholds which is doing the statistics for the Article Feedback Tool and I simply don't think that this is a good extension. (although the actual version gives the user the hint that he/she can edit the page, it still won't help to get more contributors!) <small style="font: 12px Courier New;display:inline;border:#009 1px dashed;padding:1px 6px 2px 7px;white-space:nowrap"><font color="#000">mabdul 17:52, 22 May 2012 (UTC)