Wikiversity:Community Review

From Wikiversity

Jump to: navigation, search

Shortcut: WV:CR

This page is where Wikiversity participants can discuss and review issues, attempt to determine consensus, and decide on what to do if anything. A good attitude to have is "I see a possible problem or issue, but I am not sure, what do others think?". When responding, a good attitude to have is to think of ways to resolve issues that keeps most Wikiversity participants happy and productive. Finding ways to improve things is the preferred outcome of any discussion here. Please be respectful, polite, civil, and considerate in discussions.

[edit] How to list a page here

Add {{auto subpage|page=<page>|preload=Wikiversity:Community Review/preload}} to the end of this page. Replace <page> with a short descriptive name and save. If a link appears at the bottom of the page, click it to add your comments, otherwise the page already exists and you need to pick another name.

[edit] Useful resources

Contents

[edit] Current reviews

[edit] Usurpation

There has been some question about how we should handle requests for usurpation, esp. in light of Single User Login. Please review the following pages and discuss below. --mikeu talk 13:14, 13 September 2009 (UTC)

[edit] Discussion

Speaking for myself (and mikeu, I'm pretty sure), my approach to date has been to be conservative when it comes to usurpation requests, which is to say I haven't granted requests when the target account has edits. Given that there's no clear statement by the community about whether to usurp in other cases, this is the safer course since we can always do one later. Personally I don't see any pressing need to do it in cases where another user has already made edits connected with the target username.

As far as I can tell, there's 3 ways to do it:

  1. only allow usurping of accounts that either have no edits at all or where the current owner of the username gives explicit permission
  2. allow usurping of accounts which have less than a certain number of edits and/or have been inactive for a certain amount of time, or
  3. decide cases that don't fit the first description on a case-by-case basis using something similar to WV:CR.

I think the second way has problems, and the third way might be a bit onerous. --SB_Johnny talk 13:53, 13 September 2009 (UTC)

Yes, I have been very cautious in considering these requests due to the lack of a clear statement from the community. Personally, I might be inclined to support the usurpation in cases where there are no significant edits, however this can be rather subjective. In any case, our request page has been stalled at times and the crats really need some input from everyone on how we should handle these cases. Number #3 would mostly certainly cause stalling of our progress on deciding on these requests. While I might tend to go with #2 I doubt we would be able to come up with a set of rules that is clear and everyone agrees upon. --mikeu talk 14:02, 13 September 2009 (UTC)
Just to expand a bit on my prior comment. Option #1 seems to have wide support, though I do have concerns that it might be too strict. I would support #3 as a sort of appeals or review process for cases that are not so clear cut. For example, a literal interpretation of #1 would preclude usurpation in a case where an account only has a single edit that was reverted as vandalism. As someone who clicks the button to make these changes I'd like to have a clear guideline that covers the majority of cases. But, I do support the idea of having some flexibility in making these decisions. --mikeu talk 21:11, 16 September 2009 (UTC)
I agree with number 1: Protecting existing user names of people who may some day return and continue editing is more important than giving new users exactly the user name they want. StuRat 14:58, 13 September 2009 (UTC)
I think that position may have made sense prior to SUL, or at least there was no good reason to muck things up; but since the implementation of SUL, it's important to look at the effect across projects because it affects editors here who want SULs and it affects editors who might come here (and some come the first time merely because of SUL). If you implement a rule like the above, a person can end up with an account that is unified throughout all but one or two projects because a user years ago made a few edits and left. That defeats the whole purpose of SUL. Besides, only very experienced users generally will be able to check a username across all projects for use and then be able to figure out whether particular non-English projects will allow you to usurp if it's registered. Changing a user name once you have an SUL is not a practical option. Sure, if you find that on one project there is an active editor by the same name then you picked the wrong name if you intend to edit there, no argument. But, the meta page on SUL talks about a sort of superiority of claim. Yes, it leaves that for the individual projects to define, but the implication is simply what I just stated, you can't expect to go stealing away active editor's names. But there should be some level of discretion for what clearly appear to be abandoned accounts. By the way, an SUL usurpation really is only relevant to older and less active accounts as active or newer editors will generally have taken the time to obtain SUL accounts by ensuring they had names that were available for SUL (or creating them automatically, thereby reserving the name on most projects). The crats above know this, but just so it's clear to everyone else, I have an SUL usurpation request pending since last December, so you know that I have a bias.--BewareofDoug 22:26, 13 September 2009 (UTC)
I agree with the first approach. I think the person that registered the name locally has "superiority of claim". I think the first approach is the only way to assume good faith and prevent confusion should a person return some day. If changing a SUL username is hard then SUL should be fixed. SUL could maybe even be changed to allow usernames to be different across projects while maintaining a single login. -- darklama  14:21, 14 September 2009 (UTC)
That's a great idea and maybe it should be but it's not. In the particular case that brought this here, the user has no mainspace edits, last edit of about 60 total was over 3 years ago, and the user has another account (also not used in over 3 years) which exists on multiple projects suggesting that that account is (or was) the primary account. Does your position regarding such an account remain the same?--BewareofDoug 20:23, 18 October 2009 (UTC)

[edit] multipage upload form proposal

It seems that there are two issues that we need to decide. The first is the question of a multipage upload form, which requires a change to the Wikiversity MediaWiki installation. The second is the content of those forms, or a change to our existing single page form if we decide not to go with multipage. There seems to be some support for some kind of multipage form, though we need to discuss the contents in more detail. Let's discuss below the first point about multipage upload forms. Please indicate if you agree or disagree that we should pursue this. The change that we are talking about is to add $wgForceUIMsgAsContentMsg = array( 'licenses', 'uploadtext' ); to the Mediawiki installation which will allow us to create multipage upload forms that explain the various license options. Once we choose between keeping/modifying the existing one page form or the multipage, we can than start discussing the content, choices and wording of the text. --mikeu talk 14:06, 23 August 2009 (UTC)

Please see the comment from Darklama below. We could have both a multipage and a simpler single page. This is not really a either/or question as I might have suggested above. The question that we are asking below is if you support or oppose adding the multipage option to wikiversity. Later we will draft the content of the forms for review by the community. --mikeu talk 17:52, 13 September 2009 (UTC)
  • Symbol support vote.svg Support - the single page form is too limiting and (in the current state) too confusing. Switching to multipage will allow much greater flexibility and ease of use, esp. for newcomers to wikiversity. --mikeu talk 14:09, 23 August 2009 (UTC)
  • Symbol support vote.svg Support - absolutely, we're way behind the curve on this. --SB_Johnny talk 14:14, 23 August 2009 (UTC)
  • Symbol support vote.svg Support - but with conditions & reservations:
    • Pictogram voting comment.svg Comment - How good of a repository is Wikiversity compared to the Commons, anyway? I think the smart thing to do is direct uploads to the Commons by default if that can be done. Wikiversity could have a buffer repository for developing original media and images that go to the commons when finished. Wikiversity should develop a culture of originality and resourceful adaptation. That would leave Wikiversity's repository for Fair Use media and images only... and we would need a mechanism for approving these before anyone even thinks of uploading them. Fair Use media and images reside elsewhere on the web and can be linked to for review though a Request for comments process of some sort. I don't know the answer, but I don't like to see stuff uploaded then deleted. I'd rather issues be resolved before they become issues. My $.02 worth. CQ 15:31, 23 August 2009 (UTC)
      • Pictogram voting comment.svg Comment I agree that a large percentage of our uploads would be better at commons. My feeling is that having a multipage upload form could allow us to steer Free Content License works to commons, while still allowing fair use uploads here. There might also be situtations where a large number of uploads of similar images for a learning project could be seen as duplicates at commons, and therefore deleted. But, that is a topic for another thread. First, we need to make a simple decision on single page vs. multipage upload forms. I think that the multipage form would allow us the flexibility to implement your suggestion, or other suggestions that might be proposed. The current single page form limits our ability to ditinguish by license type, which is the first step in directing people to the best place for the upload. --mikeu talk 15:40, 23 August 2009 (UTC)
  • Symbol support vote.svg Support In fact; HIGHLY support (10 on a scale of 0-10) because I HATE having to upload files one by one. Also, I think this should apply universally on all the wikis, ESPECIALLY commons. Deathgleaner 20:06, 28 August 2009 (UTC)
    • Pictogram voting comment.svg Comment This change to the upload form would still require uploading files one by one. I'm not sure if there is any way to allow multiple uploads. --mikeu talk 20:23, 28 August 2009 (UTC)
  • Symbol support vote.svg Support Both an upload form with all options like now and different upload forms with narrower scope is possible, this isn't really a single vs multiplepage issue. This approach would provides more choices -- darklama  14:49, 13 September 2009 (UTC)
  • Symbol support vote.svg Support Although I appreciate the brevity of the form, as it stands today, it isn't really all that easy to bend it to fit the exingencies of complex licensing options.--Graeme E. Smith 22:05, 21 September 2009 (UTC)
  • Symbol support vote.svg Support It's especially important in an academic site like this one, because materials commonly fill more than one page. --AFriedman 05:55, 19 October 2009 (UTC)

[edit] Move to close

I think it's time to make the bugzilla request. --SB_Johnny talk 10:49, 27 October 2009 (UTC)

Agree, it doesn't look like there is anyone oposed. --mikeu talk 13:57, 27 October 2009 (UTC)