Wikinews talk:Permission expiry policy/Archive 1
|
|
This is an archive of past discussions from Wikinews talk:Permission expiry policy. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current page. |
Privilege exposure limitation
- This discussion has been moved here from the policy water cooler. --Pi zero (talk) 12:15, 20 September 2012 (UTC)
- The following discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Passed. --Pi zero (talk) 03:38, 14 October 2012 (UTC)
{{flag}}
It's been bitched about before, but there are far too many utterly inactive accounts with elevated privileges. We've danced around this, and not done anything. I think it is time to deal with it.
People may-well ask why? Think of it first in-terms of security. Any unused account with elevated privileges is bad. An attacker, trying one random password every five minutes (to remain stealthy), gets over 100,000 guesses a year. Second, removing privileges from unused accounts is not a reflection on the account-holders. Work or studies may make contributing in a meaningful manner well-nigh impossible. Lastly, policies and process are constantly evolving, better to have someone ask for privileges to be re-granted, informed of policy and process updates, and re-integrated into the contributor base. The alternative is doing things the "bad old way" and getting their knuckles rapped for messing things up.
Thus, I think the following are reasonable proposals for changes to policy. That they should be written into policy by end-of September. And, applied shortly thereafter.
| Privilege | Status | action to be taken |
|---|---|---|
| Bureaucrat | No edits past six months | Request steward downgrade to admin |
| Administrator | No edits past six months | Downgraded to 'normal' user |
| Either of the above | No use of relevant priv in past six months | Downgraded, or privilege removed |
| Reviewer | No reviewer actions past six months | Reviewer privilege removed |
| Accredited | No edits past six months | Accreditation revoked |
The above is simple, it doesn't take away anyone's right to edit. --Brian McNeil / talk 18:20, 27 August 2012 (UTC)
Comments
- Please discuss this proposal before diving into voting!
- I would prefer something as clear and simple implemented, not an utter mess of rules that are difficult to follow and take action based upon. --Brian McNeil / talk 18:20, 27 August 2012 (UTC)
- Several thoughts.
- Crat/admin are different from the others, as crat/admin are not in the direct line of news production.
- Reviewer seems to me to get stale with lack of practice faster than the others, and even on reviewer I have in the past proposed one year — and in preparing to make a formal proposal, I was considering whether to suggest 18 months rather than 12.
- Do I remember correctly we've already put in place a time limit on accreditation? Not for inactivity, but still, requiring request for renewal.
- In order to understand better what a dereviewer policy would do, I recently prepared a table of which reviewers had last sighted a page when, as of the day I compiled the states. Note however that not all review actions show up on the review log: a failing review, performed through the EzPR gadget, is presumably a review action but does not involve sighting a page.
- I would tentatively suggest one year for reviewers and two or even three years for crats/admins. One or two years for accreditation, not sure which.
- --Pi zero (talk) 19:08, 27 August 2012 (UTC)
- Since I've built-in downgrading within the proposal, I'd look-askance on making something as-long as three years. I've also only based reviewer on use of the privilege. The admin/crat timescales are more to do with reducing "threat/risk" profiles. So, here's a revised table:
| Privilege | Status | action to be taken | |
|---|---|---|---|
| Bureaucrat | No edits past nine months | Request steward downgrade to admin | |
| Administrator | No edits past nine months | Downgraded to 'normal' user | |
| Either of the above | No use of either priv in past 12 months | Downgraded, or privilege removed | |
| Reviewer | No reviewer actions past 12 months | Reviewer privilege removed | |
| Accredited | No edits past nine months | Accreditation revoked |
- Now, if a 'crat or admin has not-a-single-edit in nine months, that's nine months for a malicious party to try and guess their password. If they haven't used the privilege in 12 months, but have been editing, do they really need it? Reviewer, I was tempted to add a similar "no edits in nine months" but have left it as a straight year of privilege use.
- Revocation of accreditation for people who've vanished seems most-reasonable, as we have no easy way to tell if the privilege has been taken elsewhere and misused. The above leaves in-place requiring renewal every two years, which is more to do with when (and if) we ever start issuing actual credential cards. --Brian McNeil / talk 11:36, 8 September 2012 (UTC)
- With one caveat, I think I'm amenable to this:
- A not-ready review via EzPR should count as a review action. It needs the priv though doesn't show on the review log; and not-ready'ing is as important as publishing, so oughtn't have lesser status.
- --Pi zero (talk) 15:04, 8 September 2012 (UTC)
- I agree that not-readying is as-important as actually publishing. --Brian McNeil / talk 13:08, 13 September 2012 (UTC)
- With one caveat, I think I'm amenable to this:
- Er. Clarification? If a crat hasn't edited for nine months, xe is downgraded to admin, and then in another nine months without editing to normal user? --Pi zero (talk) 13:34, 13 September 2012 (UTC)
Comment Here's a point for everyone voting on this: Are your passwords strong enough?
- This is a lovely little password strength-checker. The higher the number of bits of entropy, the stronger the password. That means the longer you can keep using the same password. I've done enough hacking and cracking that I could give an hour-plus talk on password security. Your average company has crap password policies because they do idiotic things like require just a minimum of seven or eight characters then demand a couple of special characters (say, a capital, a number, and a symbol). Those help, because they widen the set of used characters; but, pardon the innuendo, length matters. If you run into an online system that won't let you set a password over, say, 15 characters then you can safely bet on that website storing the password in plain text. MediaWiki has a very good password system, so there's no excuse for having a weak password. You can even use a passphrase, and those are easier to remember. As an example, "OrwellWasWriteIn1948" has nearly 90 bits of entropy, hell is likely to freeze over before a hacker cracks that. --Brian McNeil / talk 21:37, 13 September 2012 (UTC)
- Well... they'd not crack it except that you've now suggested it.
- Is that password strength checker site trust-worthy? Seems like such a site would be in a great position to log all the passwords tested on it. And I note the URL you've given for it is http rather than https. --Pi zero (talk) 22:29, 13 September 2012 (UTC)
- This is a lovely little password strength-checker. The higher the number of bits of entropy, the stronger the password. That means the longer you can keep using the same password. I've done enough hacking and cracking that I could give an hour-plus talk on password security. Your average company has crap password policies because they do idiotic things like require just a minimum of seven or eight characters then demand a couple of special characters (say, a capital, a number, and a symbol). Those help, because they widen the set of used characters; but, pardon the innuendo, length matters. If you run into an online system that won't let you set a password over, say, 15 characters then you can safely bet on that website storing the password in plain text. MediaWiki has a very good password system, so there's no excuse for having a weak password. You can even use a passphrase, and those are easier to remember. As an example, "OrwellWasWriteIn1948" has nearly 90 bits of entropy, hell is likely to freeze over before a hacker cracks that. --Brian McNeil / talk 21:37, 13 September 2012 (UTC)
Comment Should making a news article that passes at first review count toward non-exiration of reviewer privileges? Gryllida 22:54, 5 October 2012 (UTC)
- I think not, on consideration. Writing and reviewing are distinct skills. Also, let's keep it simple. --Pi zero (talk) 01:52, 6 October 2012 (UTC)
Comment Would the candidates for expiries be warned about that in advance? Gryllida 12:35, 6 October 2012 (UTC)
- No. This point has been discussed, twice; it was one of the two issues that caused Cspurrier to cast a neutral vote, below, and that was the second time it had been discussed. I think my first response to Cspurrier below sums up my position pretty well (about token edits and political circuses). --Pi zero (talk) 12:55, 6 October 2012 (UTC)
Comment Would it be necessary to go through the community vote (RfP) to re-enable privileges after they "expired" and a user returned to being active? Gryllida 12:35, 6 October 2012 (UTC)
- The community vote can be fast-tracked, as provided for in the policy here. --Pi zero (talk) 12:55, 6 October 2012 (UTC)
- Why are users in the CheckUser and Oversight user groups currently excluded from this policy? Gryllida 12:35, 9 October 2012 (UTC)
- This is discussed below in the Comments subsection of the section called 'slight' expansion. Yonder. The reasons those extraordinary privs are not themselves subject to expiry were discussed elsewhere. --Pi zero (talk) 13:50, 9 October 2012 (UTC)
- Is this discussion refer to only English Wikinews or to Wikinews in all languages? --Brateevsky (talk) 14:30, 9 October 2012 (UTC)
- English Wikinews. The different-language Wikinewses are separate projects, with their own communities and their own policies. --Pi zero (talk) 14:35, 9 October 2012 (UTC)
Votes
I'm moving this to a vote on the second proposal, dated September 8. --Brian McNeil / talk 13:09, 13 September 2012 (UTC)
Support. --Brian McNeil / talk 13:09, 13 September 2012 (UTC)
Support, though I've also requested a clarification above. --Pi zero (talk) 13:34, 13 September 2012 (UTC)
Support.....and fully so. --Bddpaux (talk) 13:50, 13 September 2012 (UTC)
Support --LauraHale (talk) 22:06, 14 September 2012 (UTC)
Neutral For the most part this seems reasonable, I worry though that this might have negative effects upon editor retention. Inactive users sometimes return and we are better off for it. Removing rights, even if we say it is solely for security reasons, is a fairly strong sign to that person that they are not wanted. Rights expiration can be used as a tool to help bring back users who still care, but are busy. I would prefer that we include some sort of pre rights removal notice in the policy. Also for Accredited users I think it is super important that we make sure that we let the user know in every way possible that their accreditation has been revoked. It would be bad for them and the project if someone tried to verify accreditation and they were told that the person was no longer accredited. --Cspurrier (talk) 22:16, 19 September 2012 (UTC)
- The point about notification was raised... somewhere... the discussion hasn't stayed confined to this page. Somebody's talk page, I think. Notification after the fact is generally desirable, to let long-time Wikinewsies know they're not unwelcome. We don't want people coming back to make a token edit because they were pre-notified, or political circuses such as have made a mockery of community discussion and hopelessly bogged down this sort of thing in the past. --Pi zero (talk) 23:36, 19 September 2012 (UTC)
- I disagree, even a few token edits is better than nothing. I have no objection to removing privileges for security reasons, but when we use that as our primary selling point for this proposal, I find things like after the fact notification an issue. Are we trying to remove privileges for inactive accounts for security reasons, or remove privileges for out of date users? I am not necessarily opposed to the later, but I think this proposal is starting to lean that way without fully considering the implications of it. --Cspurrier (talk) 19:14, 26 September 2012 (UTC)
- I don't think we're going to agree on the "token edits" issue; taking that back to the security of idle accounts point, if someone does reappear then, yes, as part of any fast-tracked re-grant of privileges I assume they would be asked if they have changed their password and picked a strong password.
- Out-of-date users was something I carefully considered when I drew up the table of rights reductions. Right now, anyone who hasn't used their review bit in the last 12 months is very unlikely to be familiar with the rigour applied in such. Getting back up-to-speed on admin will be easier than that.
- I do appreciate your concerns over accreditation, and we've first gone the route of having a two-year term. I can, from running the reporters' email addresses, say that numerous accounts were sitting with full mailboxes until I moved hosting and got unlimited quotas. Are those users going to use their credentials for Wikinews? I very much doubt it.
- The implications of this have been considered, and discussed a fair bit on IRC. It's certainly not intended to be "cutting our noses off to spite our face", and we can hardly be accused of hiding the discussion now it is linked to from the sitenotice. --Brian McNeil / talk 19:41, 26 September 2012 (UTC)
- Probably not :). I see little reason why along with the note that prompts the token edits we could not remind them of the need for a good password and save the efforts of removing privileges and re-granting them :).
- This has definitely been a well thought out proposal and it seems to be getting appropriate attention from the community. I hope my cm did not come across as criticising the thought and work that went into this proposal. I worry that as much as we say revoking does not effect the the user's standing in the community, it will be seen as such with negative consequences on their possibility of return. I hope this does not come to be an issue and I think this proposal does largely address these issues as best as it can without pre-removal notice.
- I see the reviewers issues as distinct from the other privileges. Privilege removal makes sense completely for reviewers for just being out of date, our standards have improved enough over time that a returning inactive user probably would not be able to do a good job without some catchup time. If we were not so hard up for reviewers, I would say 6 months is longer than is desirably. Accreditation I also have no objection to revoking for inactivity, as long as we are very careful to let them know (after the fact is fine) because it has significant real world consequence. 99% of the time this will be a complete non-issue, they are gone and not coming back, but I can imagine a situation in which an active user of a sister project who got accreditation trying to use and discovering they lost it in the worse possible way. For everything else a quick note on their talk page is more than enough, but I hope that for any removed accreditations we make the extra effort of email user, notify them on other wikis, etc
- Random other comment: In regards to regaining privileges, it would be nice to clarify a bit how we see the regaining privileges thing. If the person gets a single oppose regaining privileges does this matter? Do they than become ineligible for the fast track, or is it treated like RFA and is community consensus as interpreted by the bureaucrats closing the request --Cspurrier (talk) 21:11, 26 September 2012 (UTC)
- My intention in the wording there was that fast-tracking would not occur if there were an objection. The nomination is made, and under certain circumstances it can be closed as successful after only two days — but one of the disqualifying circumstances is that someone (a Wikinewsie, that is, someone who actually has a vote) objects. In that case the RFP can't be closed early. I see fast-tracking as something that ought to be uncontroversial; if there's controversy, the reasoning goes, best go through the full process. --Pi zero (talk) 22:34, 26 September 2012 (UTC)
- I disagree, even a few token edits is better than nothing. I have no objection to removing privileges for security reasons, but when we use that as our primary selling point for this proposal, I find things like after the fact notification an issue. Are we trying to remove privileges for inactive accounts for security reasons, or remove privileges for out of date users? I am not necessarily opposed to the later, but I think this proposal is starting to lean that way without fully considering the implications of it. --Cspurrier (talk) 19:14, 26 September 2012 (UTC)
- The point about notification was raised... somewhere... the discussion hasn't stayed confined to this page. Somebody's talk page, I think. Notification after the fact is generally desirable, to let long-time Wikinewsies know they're not unwelcome. We don't want people coming back to make a token edit because they were pre-notified, or political circuses such as have made a mockery of community discussion and hopelessly bogged down this sort of thing in the past. --Pi zero (talk) 23:36, 19 September 2012 (UTC)
Support, seems reasonable. Where will this be documented, once adopted? -- Cirt (talk) 03:03, 20 September 2012 (UTC)
- I think it'd be best on its own policy page. How about Privilege expiry policy (WN:PeP)?
- Which prompts the following question: Should this be moved there, with the vote moved to the talk? This would make flagging the discussion have far higher visibility. --Brian McNeil / talk 07:01, 20 September 2012 (UTC)
- Moved. --Pi zero (talk) 12:18, 20 September 2012 (UTC)
- Created. --Pi zero (talk) 13:46, 20 September 2012 (UTC)
Support Seems pretty reasonable to me. —Tom Morris (talk) 17:44, 25 September 2012 (UTC)
Support If you don't edit WN anymore or don't use your Admin etc then why keep it? If the user(s) are trusted members, then I don't see why one can ask to be re-evaluated. I know I have not been around a while and I also accept that if I lose my rights as an admin or etc, then that's ok with me. I know that if it ever came to that, I could reapply. DragonFire1024 (Talk to the Dragon) 22:47, 26 September 2012 (UTC)
Neutral I Eco Cspurrier's concerns. It is sad to remove once trusted users position of trust. However, I also note over time policy changes and if you have not stayed current you will come back to a completely different site Brian | (Talk) | New Zealand Portal 14:00, 28 September 2012 (UTC)
- See also the talk section further down, #Template. --Pi zero (talk) 20:47, 29 September 2012 (UTC)
Support Gryllida 23:28, 8 October 2012 (UTC)
Vote closure
- I'm of the opinion it's time to start moving to close this and make this policy.
- For fairness, I believe setting the vote closure date as 23:59, October 13 2012 is fair. That's a shade over a full month since this was moved to voting.
- I'm conflicted over whether or not such a policy change merits sitenotice inclusion. I know some virtually dormant privileged contributors still follow what's published on Wikinews. I believe they should have a say on the policy—perhaps being encouraged when they read articles to have a peek at RC and zap the odd bit of spam or vandalism—but, I don't want this to get 'ugly'; Pi zero's "political circuses" remark is what most-discourages me from going ahead and putting it in there for logged-in users.
- Since Craig has voted neutral above, and is one of our 'crats, I'm going to ask him regarding posting something along the lines of the following:
- The Wikinews community is considering a policy change related to user inactivity. The deadline for input on this is October 13.
- The caveat I'd attach to that is judicial application of community consensus, with the emphasis on community. I don't think anyone can be considered part of the community if they've not contributed in the last couple of years, and should people inactive until alerted to this change shouldn't find that resetting timers (i.e. those who've no edits before Dec 13, and would lose privs under this policy, don't get to keep them by involving themselves in the discussion). --Brian McNeil / talk 12:40, 23 September 2012 (UTC)
- You mean, of course, "... The deadline for input on this is October 13." ;-)
- Re perception by folks who have left, I recall the brief return, a while back, of a user who had been briefly active and been granted the reviewer bit about a year earlier. It apparently never even occurred to xem xe might still have the review bit. --Pi zero (talk) 13:35, 23 September 2012 (UTC)
- Gah. I got one September, but not the other. fixed now in case inadvertently copied. --Brian McNeil / talk 15:14, 23 September 2012 (UTC)
- Re perception by folks who have left, I recall the brief return, a while back, of a user who had been briefly active and been granted the reviewer bit about a year earlier. It apparently never even occurred to xem xe might still have the review bit. --Pi zero (talk) 13:35, 23 September 2012 (UTC)
- No response from Craig, so I've popped a mention in the sitenotice for logged-in users. --Brian McNeil / talk 14:40, 25 September 2012 (UTC)
- The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made on the appropriate discussion page, such as the current discussion page. No further edits should be made to this discussion.
Technical issue of "not ready"
Any ideas on how we spot not-ready reviews?
My initial thought was a couple of hidden categores on the article talk inside the not ready template. But, just now we frequently end up zapping those articles when they become stale.
Looks like another to-do for NewsieBot (talk · contribs) that we've wondered about for a while - userspacing abandoned/stale articles - would be needed. --Brian McNeil / talk 16:27, 20 September 2012 (UTC)
- Not-ready reviews via EzPR are easily spotted in Special:Contributions by string-searching for either "not ready when" or "article needs improve". If necessary one can switch from most-recent-50 to most-recent-500, of course. The edit summary is generated by EzPR and is always the same.
- No need for a bot for this. :-) --Pi zero (talk) 17:14, 20 September 2012 (UTC)
- And, of course: Special:DeletedContributions/Pi_zero can similarly be searched. <slaps forehead>. --Brian McNeil / talk 17:28, 20 September 2012 (UTC)
- <facepalms> --Pi zero (talk) 17:47, 20 September 2012 (UTC)
'slight' expansion
This isn't intended to wikilawyer the proposed policy, just to frame it more in-line with other policies. --Brian McNeil / talk 21:15, 20 September 2012 (UTC)
Proposed page content
The Wikinews Privilege expiry policy is one where some elevated privileges on-project may be removed due to inactivity/lack of use.
Introduction
Any wiki project changes over time. The community's consensus moves; rules and policies evolve, and methods of carrying out tasks change. Thus any individual entrusted with elevated privileges who becomes inactive, or does not use a privilege over a prolonged period of time, ceases to be familiar with current practice.
Unused privileged accounts, excluding those with extremely strong passwords, also pose a security risk through an increased attack surface. Good security practice dictates that such accounts should have unused privileges removed.
Application of the policy
The following table summarises the policy's rules governing privilege removal.
| Privilege | Status | action to be taken | |
|---|---|---|---|
| Bureaucrat | No edits past nine months | Request steward downgrade to admin[1] | |
| Administrator | No edits past nine months | Downgraded to 'normal' user | |
| Either of the above | No use of either priv in past 12 months | Downgraded, or privilege removed[1] | |
| Reviewer | No reviewer actions past 12 months[2] | Reviewer privilege removed | |
| Accredited | No edits past nine months | Accreditation revoked |
- Once a bureaucrat is downgraded to administrator, the clock starts for inactivity as an administrator.
- A not-ready review via the Easy Peer Review tool is a reviewer action, although it does not appear in Special:Log/review.
- CheckUser and Oversight are currently excluded from this policy.
Notifying affected users
To avoid conflict, a note should be left on the talk page of any user who loses privileges under the policy. This should explain the privilege has been revoked due to lack of use; not as a reflection of, or comment on, the user's standing in the community.
Regaining privileges
Re-granting of privileges revoked due to lack of use should be less-onerous than initially obtaining the privilege. A period of re-acclimatisation with the project, being active, becoming familiar with current policies and observing current use of said privileges can be followed with fast-tracked request for the rights to be reinstated.
Comments
- I've got a clarification to request, and a qualification to suggest.
- Clarification: Do we (as I would suspect) intend to exempt users with checkuser or oversight, or intend merely that those privileges are not removed by the policy? In the latter case we might, say, de-sysop a checkuser.
- If the users themselves are exempt, I suppose I should ask whether we mean Arbs to be covered.
- Qualification: The idea of fast-tracking, in section "Regaining privileges", is properly an addition to the policy, since there was no provision for it in the proposal we've been voting on up till now. If we're going to provide explicitly for fast-tracking, perhaps we should place explicit bounds on it similar to those on my proposal last April. That proposal was only for reviewer inactivity. The warily limited fast-tracking provision then, as amended at suggestion of BRS, read:
- Under certain limited circumstances, such a request may be "expedited".
- To qualify, the user must be in good standing, have had the bit removed only for inactivity, and have actually used the bit before its removal.
- If at least two trusted users (admins, reviewers, etc.) support restoring the bit, and the request has been open for a couple of days with no doubts expressed nor expected, there's understood to be no need to keep it open longer.
- Will give some thought to how these principles might be cleanly phrased here.
- --Pi zero (talk) 22:04, 20 September 2012 (UTC)
- Good questions, and a most-reasonable qualification of 'fast-tracking' back to a privved status.
- Let me try and tackle them in easiest order:
- I am of the opinion ArbCom membership is distinct from any privileges.
- That means a non-admin ArbCom member may require an admin disclose information to them only available as an admin - should an ArbCom case require they have that information.
- CheckUser and Oversight are, I believe, a superset of admin rights. One could not function effectively in either role without the same access to data (such as deleted pages) as an administrator.
- I've assumed that means we wouldn't mess with the priv-bits of those people.
- In theory, CheckUser could operate without delete, revdel, and block. In practice, not. Oversight can't be separated from delete as it's a super-delete. --Brian McNeil / talk 23:16, 20 September 2012 (UTC)
- Those answers fit with my understanding of the issues. I've proposed a draft on the page, with the following differences from your draft above: diff. --Pi zero (talk) 00:21, 21 September 2012 (UTC)
┌────────────────┘
That looks spot-on. I suggest we give this another week or so. I very much doubt anyone who has expressed an opinion will object to these clarifications.
My outlining of the policy in an as-simple-as-possible format (the table) was aimed at putting the concept across quickly, and with a minimum of drama. --Brian McNeil / talk 08:51, 21 September 2012 (UTC)
Just one more thing ...
Accreditation has a raft of off-(this)-wiki implications:
- Reporters' email address.
- Access to the JWS closed wiki.
- Possible access to the Editors' blog.
Obviously I'll manage the necessary technical aspects of this. What anyone with these 'perks' would see is:
- An email notice their account is being closed down (with some grace period to retrieve email for those who rely on webmail).
- Following the grace period, the account would be deleted, and a same-name forwarder created pointing to scoop.
- Full blocking of the account; account renamed to a _closed-salt to prevent any level of access.
- Downgrading of Editors' blog account to basic subscriber.
--Brian McNeil / talk 09:03, 21 September 2012 (UTC)
Making keeping track easier
I've created a new template, {{Privved-user}}, and applied it on the list of administrators to make checking easier. --Brian McNeil / talk 12:18, 23 September 2012 (UTC)
Template
I'd welcome any, and all, input on the formulation of {{PeP applied}}. --Brian McNeil / talk 09:08, 28 September 2012 (UTC)
- I like it. Added a cross-reference from the notice section of the policy. --Pi zero (talk) 12:33, 28 September 2012 (UTC)
- Glad to hear that. I'm tempted to do an edit on the graphic to show a desk overflowing with paperwork. One of our most-common causes for losing regular contributors is they start in the final years of school and college simply overwhelms them to the extent they can't keep up.
- I would welcome as-wide input as possible on this being a "friendly" template. I'm out to allay the concerns Craig raises above, to act as a 'gentle push' to get re-involved — even if at a far-lower level, and to ensure that people don't view privilege reduction as any sort of vindictive or victimising process. --Brian McNeil / talk 13:24, 28 September 2012 (UTC)