Wikinews:Water cooler/policy/archives/2011/March

This is an archive of past discussions from Wikinews:Water cooler/policy/archives/2011. 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.

Wikinews:Guidelines for class projects

Per a past discussion in the proposal section, I've created the Wikinews:Guidelines for class projects. I hope you don't mind me marking this as a policy; but if you do, please add appropriate categories/templates. Hopefully this page will be of use. --Piotrus (talk) 22:23, 4 March 2011 (UTC)[reply]

Re-opening worm of cans: Radically alter or dump the develop-review-publish process

The review process as implemented on en.Wikinews is strangling the production and publication process, and more importantly is preventing growth of the community.

When Wikinews was first established a similar review process was in place. It could neither scale nor support the necessary radical growth model for an online wiki community. When it was scrapped, the community grew rapidly, and article production grew. Both active community and article production peaked when processes for article development were implemented - as soon as "articles in development" were removed from the main page in fact.

I don't want to get into arguments about the history of Wikinews. Here is the net concern: if we drop the review process or radically alter it to allow instantaneous publishing (instant gratification) with easy unpublishing model we put at risk our listing on Google.

Google traffic has been good for en.WN. But it has not increased our editor pool, which ultimately means it is not helping to maintain the project. In my opinion it's worth risking our listing to improve the editor pool size and diversity. The status quo seems to be leading to slow death with a handful of active participants on a cobweb of a news blog. - Amgine | ^t 18:36, 5 March 2011 (UTC)[reply]

Three possible options

There are many ways we could relax the review process. The three primary ones are:

Easy unpublish: articles may be published immediately, but *anyone* may remove an article from publication. This is a sure way to create drama, but it also makes people passionate about their writing. Are we willing to live in a very hostile space?
- Cons:
  - In the past it was used to strategically prevent an article being published (a cabal of users repeatedly unpublish an article whose content they disagree with.)
  - Causes drama when writers feel ownership of articles.
- Pros:
  - Very fast publication, either by the author or anyone else. (Thus excellent contributor gratification)
  - More engagement: even casual readers can unpublish (or publish) an article.
  - Excellent gratification for admins/wikignomes: zapping spam or tagging article problems have immediate, visible results on the main page.
  - Justifies having articles in development on the main page.
Super-streamlined review: everyone can review articles, and we cut out the vast thicket of instruction creep in the review process. Tell people what they should be looking at, but get rid of the very painful and problem laden 'request for permission'. A revised EzPR script which is a single pass/fail, and comments section.
- Cons:
  - A hurdle to overcome; slows publication.
  - Trust metric won't exist.
- Pros:
  - A hurdle to overcome; slows publication.
  - More engagement: even casual readers can review/publish articles.
Complete anarchy: Everything which is current in main namespace is listed as a published news article, and only those which are tagged in some way are not published. A variation of the first method, this is also the most vulnerable to marketers. It's also, of course, the most user-friendly so new people will have the greatest positive experiences.
- Cons:
  - Everything is instantly published, so most vulnerable to marketing/SEO.
  - Causes drama when writers feel ownership of articles which get tagged with issues.
- Pros:
  - Instant publication = instant gratification.
  - More engagement: everyone can tag article issues. (Even, possibly, use feedback to unpublish articles.)

Mission question

Is wikinews focused solely on finished news articles, or is it instead focused on the production of news articles? If the latter, then the primary effort should be to make it easy and enjoyable for people to do so. A vibrant stream of articles will contain a percentage of dreck, and the larger the stream the more trash it will carry - but still only a percentage of the total flow. In my opinion the filtering systems in place now have nearly stopped the flow entirely. - Amgine | ^t 18:36, 5 March 2011 (UTC)[reply]

I would dispute that reviewing is the sole problem here (and I emphasize sole). Hast thou forgotten the wave of retirements? Can we, in all honesty, say for sure that WN would fail to grow if we could get back to the critical mass required to keep the review Q moving? That problem is created by PR. Output may be slowed by it, reduced slightly - but I question if we've actually seen enough to know if it works without drama and retirements getting in the way. I've said a couple of times recently that we need to get the Q moving, which is what prevents me from trying to suggest recruitment methods - without the base of editors we once had, how do we get enough to stay that more will feel like joining in? Who feels like analysing figures to see if we can tell enough about PR versus drama? Blood Red Sandman ^{(Talk) (Contribs)} 19:21, 5 March 2011 (UTC)[reply]
I should mention that the peak I'm referring to was in 2006, rather pre-dating the 'wave of retirements'. That's why I didn't bring this up last fall - it would have been conflated erroneously. - Amgine | ^t 19:28, 5 March 2011 (UTC)[reply]
But, how big a drop are we looking at, and how sustained? How have daily article-views (in a comparable sense to man-hours, that is) gone up or down since? And, has it really dropped low enough that it surpasses increased quality in value? None of these are rhetorical questions. I don't have a clue. Blood Red Sandman ^{(Talk) (Contribs)} 19:34, 5 March 2011 (UTC)[reply]
We averaged 25 news articles a day for a month. - Amgine | ^t 19:38, 5 March 2011 (UTC)[reply]
(edit conflict) For reference, you might be interested in this. Userbase and article writing have been gradually decreasing since 2006, but saw a particularly sharp drop in June-September of last year. Tempodivalse [talk] 19:40, 5 March 2011 (UTC)[reply]

Thanks Tempo, useful. Having been thinking this over since Amgine's initial post, perhaps the move required is to scrap necessity for review for certain people. This still leaves the problem of getting electric cattle-prods up people's bums to review newbies' work, though, which is the hardest - but, without factchecking stuff from users known to get it right, we might see more people going in for it. Once people know what they're doing, they get the right to publish handed out to them. Blood Red Sandman ^{(Talk) (Contribs)} 19:50, 5 March 2011 (UTC)[reply]

I don't see omitting review for some people as at all viable. Some considerations:

Doesn't that explicitly violate the conditions under which Google news accepts our feed? [+Note: ack, Amgine was up-front in mentioning this.] (Regarding the significance of that, see also my comments further down in this post about the big picture.)
Nobody is immune to making mistakes, so everyone needs to have someone check them.
In my experience, the best authors are (often) easiest to review, so that they may represent a relatively smaller fraction of the reviewing workload. So for the terrible price paid to not review their work, we get relatively little benefit.

Some thoughts on the big picture.

My view of the overall approach is that either a project grows, or it dies. I see our peer review system as growth, and I believe if we take a step backward from it, that's a fatal step. I've been grumbling publicly for at least a year (I think) that we need to find a way of meaningfully splitting up the review task among multiple people, which I believe will enormously increase our review performance (though perhaps not instantly so). My hypothesis is that the limiting factor here is not so much a shortage of qualified reviewer time for review, but a shortage of large chunks of qualified reviewer time for review. I suspect a lot of us could donate at least a little more time to review, in total, if we could do it in smaller units. (I brought this up on a thread on this page that's still visible now, above.)
Regarding behavioral guidelines, I'm convinced AGI is something that needs to be replaced (not supplemented) in the long run, and I've even got some notes on the problem that I've been hanging back from putting up in my user space for a few weeks while I tried to neatify them some more. I've also come to believe, though, that they are all missing an essential element: they are all essentially pessimistic, i.e., they're about how to avoid bad stuff. The egregious AGF, which I believe has done much long-term harm on Wikipedia and will become more and more obviouly dysfunctional there in the future, has one big merit that cannot be dismissed easily: it is pie in the sky idealism. Thinking back, one of the things that got me most excited about Wikipedia, long ago when I first registered and was welcomed there, was that the whole project was apparently made up of completely unrealistic idealists who were willing to make a real effort to make their ideals work. AGF itself isn't what's needed, for either project, but that doesn't mean its role as an idealistic dream isn't needed.

--Pi zero (talk) 22:02, 5 March 2011 (UTC)[reply]

An addendum to the above: We do have idealistic goals that inspire. We believe in accurate, neutral citizen journalism. And that is, as I suggested above, a huge deal, that we have ideals that can inspire passion. Breaking peer review would betray the ideals, which would do for the moral fabric of Wikinews approximately what commercial advertising pop-ups on all content pages would do for the moral fabric of Wikipedia. --Pi zero (talk) 23:20, 5 March 2011 (UTC)[reply]

I think http://www.codesimplicity.com/post/open-source-community-simplified/ is a relevent article to our situation that we should perhaps consider. Also I feel a good step in the right direction would to be make stale articles publishable, but make them appear under a date a couple days ago. Its really disheartening for people to say their work deleted. Timeliness isn't everything in the world Bawolff ☺☻ 00:23, 6 March 2011 (UTC)[reply]

Publishing stale articles, as a mitigation for the frustration of having one's article deleted. It's like deja vu all over again. That is (more or less) an idea I was enthusiastic for in the first water cooler discussion I ever participated in.

Would the late-published articles appear in the headlines list on the main page? 'Cause if so, I don't know how you'd make them appear further down the list. --Pi zero (talk) 01:05, 6 March 2011 (UTC)[reply]

Historically we used to do per date on main page. We no longer do that. We could still add a late publish category to it to stop it or something. Thats really more a technical issue to work out. Whats more important is the social issue of lets allow it. Once we decide we want something, the hard parts done, only implementation is left. Bawolff ☺☻ 01:08, 6 March 2011 (UTC)[reply]

I have a few points here:

First, I might be willing to support stale article publication, depending on how it is implemented. It really is a huge blow to new writers to see their work deleted — especially when it isn't (entirely) their fault (IE, it initially fails review, the author fixes the problems, and then it sits in the review queue for 72 hours because no one will touch it. Then it is deleted).

Secondly, I like Pi zero's "multi-segmented review" idea. It wouldn't fix every problem, but it might well help.

Thirdly, removing the need for peer review for regular writers is a bad idea. As someone already mentioned, prolific article writers are the easiest, least time consumptive to review. Newbie articles not only take forever, but also require a significant amount of work on the part of the reviewer. Personally I tend to do the easiest reviews first, which are usually writers that I know probably did a good job with their article. Gopher65_talk 02:00, 7 March 2011 (UTC)[reply]

Review process issues

I'm curious about the early days review process that was in place; it obviously predated the technical ability to enforce an independent review, but how does it stack up against what we've got now? /* Wiki War-Zone */ AGI is, from my point of view, a massive red herring; it should not feature in this discussion. A publicist spamming Wikinews with a presser is "acting with good intentions", but not to the benefit of the project. I would class blind reproduction of VoA, BBC, RT.com, or China's state controlled media as the same (were the latter PD as is VoA).

So, there's a need to take several steps back and ask what is Wikinews supposed to achieve? Perhaps, looking at what has been achieved already. —The preceding unsigned comment was added by Brian McNeil (talk • contribs) 22:52, 5 March 2011 (UTC)[reply]

Questions to ask yourself

How important, as a contributor, is having your work listed in Google News?
How many of Wikinews' stagnating contributor base issues are due to the community itself?
1. How many to worship of Wikipedia's almighty pagerank? (Thus being selfish enough never to write here.)
2. How many to The Other Place's unwillingness to enforce their "not a news site" policy?
Does the average noob actually see the biases in their preferred news sources?

—The preceding unsigned comment was added by Brian McNeil (talk • contribs) 22:52, 5 March 2011 (UTC)[reply]

We really should stop defining ourselves in terms of Wikipedia. Wikipedia will do what is best for Wikipedia. It is good for Wikipedia to have articles on current events. They are different from what we do here, or at least I consider them to be different. Bawolff ☺☻ 01:19, 6 March 2011 (UTC)[reply]

It would be nice to have that luxury, we don't. They, near-constantly, overstep encyclopedic bounds and make contributing here well-nigh redundant. --Brian McNeil / ^talk 05:48, 6 March 2011 (UTC)[reply]

I don't subscribe to that line of thought, but for the sake of argument, lets look where this leads. There are three conclusions you can draw if you accept the premise that Wikipedia makes us redundant:

Wikipedia should change their ways to make us not redundant. This is a stupid line of reasoning in my mind because it is not Wikipedia's fault that we exist. Wikipedia has no responsibility to help make us work, nor should they.
We should close up shop and stop doing what we're doing. If anyone subscribes to this point of view, I'd ask what they're doing contributing here. (And I am aware that there are probably some people who hold this view. That is fine, not everyone has to agree with what we're doing, so long as some people agree)
We should change our ways to be non-redundant. And to a large extent we have done things differently from Wikipedia that make us non-redundant in terms of process. In essence what is being discussed here is if we've gone too far in that direction.

However, the way I see it we are not redundant with 'pedia because we have a different process, a different format of article (even if its related, it is still different), and a different scope (Overall notability is not important relative to notability of the moment, OR, timeliness, etc). Bawolff ☺☻ 06:11, 6 March 2011 (UTC)[reply]

Wiki War-Zone

Up-front, we can't implement a de-publish process without something like the GNews sitemap. Or, accepting delisting when we're caught with nonsense being self published. That isn't what I'd like to see.

Self-publish for well-established contributors is also a less-than-critical issue. Most longer-term, quality contributors know someone can be persuaded to review their work more on the basis of a copyedit and casual factcheck. —The preceding unsigned comment was added by Brian McNeil (talk • contribs) 22:52, 5 March 2011 (UTC)[reply]

Interesting point; with GNSM we could publish to Google News only those articles which have been peer reviewed, while on en.WN itself we could include both peer reviewed and not as 'published' articles. The problem, of course, is that GNSM does not exist and likely never will exist within the WMF. - Amgine | ^t 00:58, 6 March 2011 (UTC)[reply]

Closing remarks

Personally, I'm insulted every single time someone, almost invariably a Wikipedian, says Wikinews is "not a reliable source". I would be deeply unhappy to see that become reality as the only way to increase contributor base. Many of the somewhat provocative suggested solutions seem that way to me.

As to the '06 contributor drop; we had a vibrant antipodean set of pre-college contributors. Since stepping up to university they no longer have time to devote here. --Brian McNeil / ^talk 22:52, 5 March 2011 (UTC)[reply]

<shrug> I don't measure Wikinews by Wikipedia's standards. I also don't measure it by yours. The standards used here are higher than used in professional news rooms, and they don't seem to be contributing to growth. Also, you're forgetting that in '06 we had a much larger old farts population as well as pre-, mid-, and just post- college. The community was bigger. Full stop. - Amgine | ^t 00:52, 6 March 2011 (UTC)[reply]

I don't think looking back to the prior contributor base is enormously helpful unless we can identify what broke the mix. My recollection is of the Australian and Kiwi portals being most active; of there being higher conflict levels with Neutralizer and his Skull and Bones obsession, and many people bemoaning the lack of listing in Google News.

Would that the Wikipedians desperate for Mr Wales to retain an appendix-like privilege took part in this discussion; or, put their own house in order.

I can't see a clear path to revitalising the project, but would be open to suggestions. Those proposed above seem more aimed at prompting discussion than being near-usable. A completely new 'project vision' may be in order, but there are WMF-imposed constraints in addition to those, internally, surrounding verifiability. --Brian McNeil / ^talk 05:44, 6 March 2011 (UTC)[reply]

My impression is no one thing broke the mix. A gradual creep of rules, limitations, etc. made it harder to publish, which is the main "reward" of contributing. At the same time, and equally gradually, the community became less about supporting each other in doing cool/new stuff, and more about getting respect from outside the project. - Amgine | ^t 06:37, 6 March 2011 (UTC)[reply]

On wanting respect from outside, I don't see it. I see a different distraction; I'll get back to that.

Revitalizing the project. I suggest we're not very out of tune, actually, but several things about the project need adjusting somewhat. Trouble is, they've needed adjusting somewhat for a long while, and it hasn't been happening, while their ill-effects accumulate. Why not? Because one of the things that needs adjusting is —yes, I'm going to say it again— we need to make it possible to meaningfully divide peer reviews into bite-sized pieces. Wikis are good at bite-sized pieces. Do that and peer review becomes manageable — but exactly because it hasn't already been done, we all (even me) spend our energies trying to keep up with the day-to-day demands of the project to the point where these needed adjustments never happen. Thus perpetuating the need to do so.

My three leading candidates for adjustments to the project.

As above: divide peer reviews into bite-sized pieces. Far and away most important. We've got enough technical tools available to us to make this happen, I think, we just have to apply them. Do it and all else becomes possible. I mean to do some really intensive focusing on this in the near future... though I'm also hoping to review some articles, and there's that time-budgeting problem again.
Smooth community operation. I have some ideas on rules to replace AGI, but rules are by nature pessimistic. We also need optimism; idealistic enthusiasm is key for a wiki, and we do have community ideals — that we'd be backing off from if we lost peer review, so shooting ourselves in the collective foot.
Arrange that the vast majority of links in the text of articles are links within Wikinews. Note, it's not about respect from outside, but about self-image. Subtler and longer-term than the preceding two adjustments, but good for long-term project morale so not to be discounted.

--Pi zero (talk) 08:15, 6 March 2011 (UTC)[reply]

Semi-arbitrary break

Regarding splitting up Peer Review, is this technically possible (and generally desirable)? We have a system similar to the on-screen edit gadget (code) whereby as individual parts of the article are verified (and checked for copyright? At the same time? Separately? More use of automated plagiarism checkers?), they are cleared from a screen reviewers can access. Once everything's gone, then the piece can be published - of course, there'd need to be a final style check. This responds the problem that the hardest parts of review are copyright and factcheck, and that they tend to be easiest done together - which is what I've previously viewed as the problem with splitting reviews. Blood Red Sandman ^{(Talk) (Contribs)} 11:13, 6 March 2011 (UTC)[reply]

Yeah, copyright and fact-checking are likely done together, though it's possible to imagine having verified a given passage without having fully vetted it for copyright. Resistance to separating those two tasks means that splitting that biggest part of the review should be passage-by-passage rather than subtask-by-subtask.

I haven't looked into automated plagiarism checkers, to know how good or bad they are in practice. Just from general principles, human instincts when immersed in things might pick up subliminal trouble signs that automation mightn't, but the point of splitting the task into smaller pieces is so review doesn't require that depth of immersion. So maybe we can use all the help we can get.

Can we do it? Yes. Suppose our goal is something a bit like onScreenEdit, where passages are in some sense "highlighted". Meta-data is needed to track which passages are highlighted.

The meta-data can't be kept, trustworthily, in the article —assuming the article is in mainspace— because there the article can't be sighted until publication and that leaves the meta-data too open to tampering.
The meta-data can't be kept, practically, in a separate page in a non-main flaggedrevs space (e.g. template), because edits to the article would be apt to lose coordination with the meta-data.

So how about this, as a concept. I could punch holes in it myself, but imho it also shows some promise.

Have two separate namespaces for articles: a nursery for articles in development or under review, and mainspace for published articles only. (Namespace Newsroom: ? :-)
The new namespace is also subject to flaggedrevs. So when reviewing an article we can mark it up with highlighting meta-data to our hearts' content (with perhaps tools to help maintain the meta-data), using flaggedrevs to keep track of certification.
Publication would involve moving, or maybe copying, the article to mainspace, and perhaps removing the highlighting meta-data, in addition to the usual tag changes.

--Pi zero (talk) 16:12, 6 March 2011 (UTC)[reply]

(in reply to BRS) Are we sure splitting reviews between several people is really a good idea? It's tough as-is to have an article reviewed in a timely manner, and on slow days (which we have a remarkable affinity for) stories can not be published for over a day. If we ~~required~~ encouraged two reviewers, I feel review times will jump even further. That's not something we can afford - one of the biggest disappointments to newbies is that their news is already stale by MSM standards once we've released it, and thus we're perpetually stuck "behind the curve". Tempodivalse [talk] 17:39, 6 March 2011 (UTC)[reply]
Read again. There is no requirement for any given number of reviewers in the above. Blood Red Sandman ^{(Talk) (Contribs)} 17:51, 6 March 2011 (UTC)[reply]
That was a mis-wording on my part. I meant "encouragement" instead of "requirement", sorry. My concern still stands though. Tempodivalse [talk] 17:55, 6 March 2011 (UTC)[reply]
I can't see allowing people to invest more of their time as possibly slowing things down; though I have no idea wether it would speed them up. Where I would point to as a problem is the issues in moving cross-namespace being an extra step; and, how confusing might the required interface be? Blood Red Sandman ^{(Talk) (Contribs)} 18:54, 7 March 2011 (UTC)[reply]

I may be completely off-base here, but let me restate what I *think* this branch of the conversation is about: over-regulation/over-process is raised as a problem for growth and development, and a proposed solution is to expand over-regulation/over-process to incremental review stages. Did I get that correctly? - Amgine | ^t 18:09, 6 March 2011 (UTC)[reply]

I think there are two issues raised. Over-regulation/over-process, and that the process is too hard because it has to be done all at once. This I think tries to address the all at once issue by splitting it up into multiple small steps that can be done incrementally. Bawolff ☺☻ 18:19, 6 March 2011 (UTC)[reply]

In other words, a for-next loop. It may make it 'easier' for the reviewer, but it adds many more steps and at any one of them the article may be stalled/prevented from publication. If the goal is "reduce obstructions/time to publication", this does not address the goal. - Amgine | ^t 18:35, 6 March 2011 (UTC)[reply]

It seems the term "over-regulation" may mean to you "standards that are too high", but to me it does not specify in what way the regulation is overbearing. Overly inflexible regulation isn't necessarily imposing higher standards than a more flexible system. Allowing review to be split up between multiple people is (or rather, can be) more flexible. Part of the theory here, which I've articulated in the past, is that reviewers may be able to donate small bits of partial review more readily than they can donate great monolithic blocks of time for whole reviews, so that splitting up the monolith would increase the total amount of labor that gets donated. For a successful implementation of the splitting concept, visible administrative overhead must be significantly lower than this increase in available labor — noting that some administrative overhead can be hidden below the level of the user interface (i.e., in gadgetry or the like). --Pi zero (talk) 19:27, 6 March 2011 (UTC)[reply]

That is like saying each tire on a car is flat and needs to be pumped up, and we're more likely to find volunteers to only do one tire than all four. Which is likely true. But I'm suggesting we need a hovercraft. Your solution does not fix the problem. In application, based on the current evidence, it would decrease the number of articles completing review because it is the number of steps between writing and publishing, not the size of the steps, which determines completion. Incidentally, this is the exact argument used in the original review process: distributing the review process would improve its implementation. - Amgine | t 22:28, 6 March 2011 (UTC)[reply]

"I'm suggesting we need a hovercraft," - ah, but PiZ's countering the car will be fine if we pump the tyres up. Having given one suggestion as to how this might be done, I find myself leaning towards trying it first. Anything not to take the alternative route... Blood Red Sandman ^{(Talk) (Contribs)} 18:54, 7 March 2011 (UTC)[reply]

No matter how well pumped up the tyres, it's not going to cross the Red Sea. The hovercraft will. The definition of insanity is trying the same thing over and over again, expecting a different outcome. Adding more hurdles to publication will not result in more publications. By making review process modules - one for each of the various points reviewers should examine - you will increase the number of separate things which must be accomplished before an article is published, thus multiplying the review hurdle. "Let my [articles] go!", to be blasphemous about it. - Amgine | t 03:02, 8 March 2011 (UTC)[reply]

Maybe I need to explain more simply: Wikinews is not about doing reviews, it's about publishing articles. The proposal posits that making reviews shorter/smaller/easier will result in more articles being published. This does not follow logically. It is likely it would result in more reviews being done, if you consider each of the shorter/smaller/easier reviews as one review. It is unlikely the increase in reviews would be 5-6x the current number of reviews (the 5 sub-sections of the current review + the "do all reviews pass" review.) Further, it is less likely any one person will conduct all 5-6 reviews on a single article, and likely will feel doing at least one shows project commitment, leaving the article to wait for more than one reviewer. Therefore this model is unlikely to result in more successful article publications. I would even say very unlikely to produce as many, except for the short time following its implementation by a small number of editors out to "prove the model works." - Amgine | t 03:21, 8 March 2011 (UTC)[reply]

Wikinews is about publishing news. You're proposing to post blog entries, instead of publishing news. That's why your hovercraft analogy doesn't scan (whereas the person-per-tire analogy wouldn't be bad, really, if its purpose were to illustrate the point I had just made at the end of my previous post). What you're proposing would not perform action alike in kind to the system you want to scrap; so it's not like replacing a vehicle with a different vehicle. A more apt analogy would be that because the car has four flat tires you want to scrap it and instead hold a singalong.

It should be very clear, by this point, that the shape of this thread (established by its initial post, of course) naturally guarantees that Amgine's objections to the proposal can set the agenda for the thread indefinitely, making it impossible within this thread to conduct the needed constructive dialog about the proposal. A separate thread will be required for that. --Pi zero (talk) 04:38, 8 March 2011 (UTC)[reply]

My hovercraft is full of eels

[More commonly known as a required section break.]

The four tyres analogy is apt, as Amgine presents it. The required actual work remains unchanged, but you add in four rounds of recruiting someone to do each task. --Brian McNeil / ^talk 12:05, 8 March 2011 (UTC)[reply]

Recruitment? I think that's backwards (and it's not how I read Amgine's original remark when introducing the analogy, either). There are two task sizes that must be attended when designing an implementation of the divided-review concept:

The minimum required size (ante) for a peer-review contribution.

The wiki model of available volunteer labor is that while it is rare to find one person willing and able to donate a huge monolithic effort, there are lots of people who —when motivated by a compelling idealistic vision (say, reliable neutral citizen journalism)— are willing and able to each donate a smaller increment of effort. See w:Long Tail. By making peer review a huge monolithic task, we have cut off too much of the long tail; by reducing the amount of effort each individual has to invest, we tap into a larger pool of available labor.

Note that the long tail model is a profoundly different analysis of the situation from Amgine's suggestion that "it is the number of steps between writing and publishing, not the size of the steps, which determines completion". The definition of "step" may also be a source of miscommunication.

The total labor needed to fully review a given article.

It's well known in parallel programming that parallelizing a process entails overhead to coordinate the subprocesses. Here, we're looking for an increase in total amount of work done from dividing the process, but that increase in work done has be significantly larger than the overhead entailed (which is what I meant by my last remark just before Amgine introduced xyr analogy).

The person-per-tire analogy seemed to me to suggest a rather feeble reduction in per-person effort, coupled with a large entailed overhead from dividing the task — but that may, of course, be simply an illustration of how analogies can be ambiguous. --Pi zero (talk) 15:14, 8 March 2011 (UTC)[reply]

Recruitment is exactly the problem I was referring to. I believe you're very mistaken about the reality of the wiki model. Like most every other volunteer system, 80% of the work is done by 20% of the volunteers. The benefit of the wiki model is everyone can be a volunteer. With a very wide base of volunteers, you have a very large 20% who can do so very much.

By restricting who can do the work, then multiplying the number of separate tasks to be accomplished by this limited pool, I believe you're suggesting a situation with a great likelihood of failure. Especially since the current model is already failing, and you admit your model would do nothing to change the amount of work to be accomplished while increasing overhead costs. Keep in mind the reviewer caste of Wikinewsies already includes the most-active participants. - Amgine | t 16:58, 8 March 2011 (UTC)[reply]

I'm about to exasperate Brian McNeil, by making a series of comments and then taking a left turn on the last one, opening up a new set of possibilities for discussion. Sigh.

Number of steps.

The definition of "steps" is an opportunity for miscommunication. As I see it, the monolith requires one person to perform many steps, so allowing those steps to be performed by different people does not —necessarily— increase the number of steps involved.

80% by 20%.

That's not at all incompatible with the long tail effect.

There may be a long-tail effect within the 20%. Indeed, I'm already talking about a long tail effect within the population of reviewers. More on that under my next major bullet.
I've emphasized that review should not be required to be divided, and the option should not be allowed to put any additional burden on anyone who chooses not to divide it. We don't want the ability to divide it to stifle any peer-review activity that would otherwise occur, only enable further activity that would not otherwise occur.

Reviewer caste already includes the most active participants.

Roughly true, I think, but taking myself as an example — I've contributed, ballpark, maybe two thousand hours of my time to Wikinews. Yet, momentary aberrations aside, I rarely do peer reviews. Why? Because even though I donate a ridiculous amount of time, I'm rarely able to produce the monolithic effort required. If I could easily contribute smaller blocks of effort to peer-review, it seems plausible my total contribution to the overall pool of review work would go up. And (for various reasons) I don't think I'm the only one like that. Hence my suggestion there's a long tail lurking here, and it's worthwhile to provide an outlet for it and see how much of it there is.

Everyone can volunteer.

It's possible —I'm honestly unsure myself and would like to get wider feedback on this— that dividing the monolith could also present an excellent opportunity for entrusting the most massive part of the reviewer task to a significantly larger class of users. The trouble with the current reviewer class is that it's the intersection of about three sets of users:

Those with specialized knowledge of how we do things — not exclusively the Style guide, but that's a big part of it.
Those who are trusted to take the work quite seriously.
Those who are trusted to do the whole massive task thoroughly.

Does it seem, though, that the massive monolithic heart of the thing, copyright/fact-checking, doesn't require as much specialized knowledge? A bit of instruction and maybe some sort of cross-check that the principles are understood, but not the Style guide or such. And dividing the task per-passage ought to alleviate the issues with entrusting users to do a massive task thoroughly.

So, what if someone experienced did a first-pass style check, then copyright/fact-checking was open to incremental work by a larger group, and someone experienced did a final check and published? Or some variant; suddenly there's a whole host of new possibilities (a mixed blessing, indeed).

--Pi zero (talk) 19:15, 8 March 2011 (UTC)[reply]

I believe I've mentioned this a few times, but, this doesn't seem to address problem, which is how long/how difficult to get published. What you're saying is: our current output (and trends) justify our current process. I'm saying they don't. - Amgine | t 20:23, 8 March 2011 (UTC)[reply]

"Miscommunicating" scarcely seems adequate. (For example, I consider your first two sentences blatantly false — but that's just an example.)

The communications failure may look symmetric on your side to what I see. It's probably time to admit we simply can't bridge the gap — painful though that's likely to be, as we both clearly care deeply about what we've been trying to communicate. --Pi zero (talk) 21:40, 8 March 2011 (UTC)[reply]

Pi, you exasperate me because you lay out a set of bullet points, then rephrase exactly the same solution as you've done throughout the rest of this discussion. We've all seen cases where someone experienced goes "OMG!" at appalling stylistic, neutrality, or sourcing issues; they fail on some/all of these, and the article isn't fixed. This discussion has become useless. Some people are entrenched and others are being sucked into fiddling with deckchair arrangements that constitute their pet projects. And, despite dozens of section breaks, you in particular Pi, overload each section beyond any readibility index. Let me know when someone's an idea that meets my one simple criteria: Keeping a GNews listing. --Brian McNeil / ^talk 20:38, 8 March 2011 (UTC)[reply]
<snorts> and you accuse me of entrenchment? <wink> - Amgine | t 21:26, 8 March 2011 (UTC)[reply]

Brian, to be clear, none of my posts have been intended to fulfill your request for concise bullet points. --Pi zero (talk) 23:18, 8 March 2011 (UTC)[reply]

"Something must be done; this is 'something', let's do it."

Forgive the section break heading, it's an old political joke - and indicative of what seems a circular set of arguments being presented.

At one extreme we've anarchy and no review - with what would become conflict with unpublishing and so on.

At the other end we've the physist and engineer, the latter arguing that they can reach a goal by covering half the remaining distance in each step.

What, as concise bullet points, are the arguments in favour or against either? --Brian McNeil / ^talk 23:15, 6 March 2011 (UTC)[reply]

I disagree with your assessment it's all or nothing. However, there is a brief listing of three possible options up the thread; perhaps you could look there and see if they need bullets? - Amgine | t 00:42, 7 March 2011 (UTC)[reply]

I'm not saying it is all or nothing; just these seem the options being presented, (and I'm finding Pi Zero's torrent of verbiage tiring). For me, and so we're not stepping back and going through the same complaints from newbies, I just want a solution that preserves our Google News listing. --Brian McNeil / ^talk 14:46, 7 March 2011 (UTC)[reply]

Some things need to be said once. I do agree it adds up dreadfully, and thereafter concise bullet points are desirable. It's a formidable task, which I'll tackle at opportunity.

(As I remember it, the punchline was "close enough for all practical purposes".) --Pi zero (talk) 16:19, 7 March 2011 (UTC)[reply]

Yup. --Brian McNeil / ^talk 16:24, 7 March 2011 (UTC)[reply]

Brian McNeil: While it would be far preferable to keep the GN listing, as was previously pointed out in this thread it has not specifically increased contributorship. Given the choice of continued slow erosion of contributions with GN listing, or doing something which improves contributions but risks GN listing, I choose the latter. - Amgine | t 02:54, 8 March 2011 (UTC)[reply]

I do not disagree that reviewing must become less arduous. But, I assert some sort of review is required, and that such should be to a minimum level to keep the GNews listing.

First, can we reduce the number of "tickboxes" in the review template?
Second, whilst Mr Wales is participating locally, can he be persuaded to push GNSM?
Lastly, what can be done to ensure people write closer to the SG in the first pass?

Yes, your point that publication has become too challenging is valid. A free-for-all, to me, devalues - if not outright discards - all work done to make Wikinews a credible news source. We are, already, considered more reliable than Wikipedia and I want things to stay that way. --Brian McNeil / ^talk 12:14, 8 March 2011 (UTC)[reply]

Re tickboxes: I've been reckoning that copyright/fact-checking is at the heart of the concept of review, and cannot be broken up by subfunction, but only by portion of the article (which is what I propose to do). --Pi zero (talk) 17:10, 8 March 2011 (UTC)[reply]

Just a thought, might I suggest that many people probably don't follow everything in the style guide because it's so long - at 50kb+, I doubt any newbie would have the time to read it all, much less remember everything. It is overwhelming. We need a "lite" version aimed at newbies, including only the most important conventions likely to be encountered (where to put headers, {{source}}, etc.) listed. My "welcome tour" was intended to do this in a user-friendly manner. I still think it was (is) a good idea. Tempodivalse [talk] 15:55, 8 March 2011 (UTC)[reply]

Our recent significant revision to the front tab of {{Howdy}}, I consider to be addressing the same problem as the welcome tour; and although I too disapproved of the specific form of solution attempted by the welcome tour, I give it (hence, you) credit for earlier recognition of the need for something there.

I didn't see that the welcome template had been changed. That's a step in the right direction, but it ultimately just redirects the reader back to the same long, unwieldy policy pages that are so mind-boggling to the newcomer without explaining much "in a nutshell", easy-to-digest way.

Incidentally, what objections do you have against the tour in its current form? Too wordy? Not specific enough? I'd be interested to know, it's been frequently sneered at but nobody told me what exactly is wrong. Tempodivalse [talk] 17:28, 8 March 2011 (UTC)[reply]

┌───────────────────┘
The tour was excessively verbose and a duplication of the Writing an Article essay which you're choosing to overlook. --Brian McNeil / ^talk 17:46, 8 March 2011 (UTC)[reply]

WN:ARTICLE is still a good 15kb long. Compare that to the tour, which, although supposedly "verbose", manages with about 9kb, not including formatting, and a potential to be even shorter (and I contend that it's easier to digest, because it's split up into logical sections instead of one big, daunting wall of text). We're always saying concise is better, right? Of course there's room for improvement and I'd be happy if someone invents something better, but I don't see much gravity to this objection. Tempodivalse [talk] 18:59, 8 March 2011 (UTC)[reply]

Something very easy to overlook about that upgrade we made to {{Howdy}}: each of the links in those instructions has a mouseover. I lamented at the time that the mouseovers wouldn't be seen, as the alternative to the mouseovers would be to go straight from the compact instructions to the instant-TLDR's like the SG. It briefly occurred to me to suggest that we make each of them a tiny page that the link would lead to, and then users could go on from there to the TLDR version, but I hesitated to suggest it because it seemed like a lot of extra infrastructure for the user to navigate. --Pi zero (talk) 19:29, 8 March 2011 (UTC)[reply]

I did notice the mouseovers. Their usefulness is limited, however: firstly, they're easy to miss; secondly, and more importantly, most of the blurbs explain little of value themselves and just encourage the reader to read the full policy pages - and we have the same TLDR problem as before. Tempodivalse [talk] 20:13, 8 March 2011 (UTC)[reply]

BBBBreak

I'm surprised you noticed them at all; we're certainly solidly in agreement they're easy to miss. I wouldn't go quite so far as "little of value"; they're substantive expansion on points that were ruthlessly trimmed down in the Howdy template itself. We wanted the list so short and simple a newbie might actually read it. But yes, if each link were to an "intermediate" page, short of the current TLDR target, the intermediate pages would each have somewhat more in them than the mouseover. --Pi zero (talk) 23:36, 8 March 2011 (UTC)[reply]

Some mouseovers explain only very basic information that isn't enough to get a user started, and others don't explain anything at all (for instance, the 5W quote from Kipling is nice but says nothing to the user). This is why I was pushing for a welcome tour: in under nine kilobytes of text, it introduces the site's mission, how to write an article by the most important rules and have it published, and where to go for help, all in one module, and in a step-wise, easy to digest format. If we're using the "shorter is better" metric, it wins. I just can't accept that it's "verbose" (especially after a recent copyedit that cut out over 500 chars). Tempodivalse [talk] 16:31, 9 March 2011 (UTC)[reply]

┌────────────────┘
I took another look at the tour yesterday. It's in "bite-sized" 2KB-ish chunks and was roughly 12KB. But, it has three or four points at which someone can bail out of reading it.

I'll admit, my "In a nutshell" piece is ~14KB. However, that uses repetition (effective learning method), and puts decoration at the end - so you could have the fundamentals by the time you're a third of the way through it.

Lastly, to be blunt, the tour's colour scheme is <unprintable-string-of-expletives-ommitted>. --Brian McNeil / ^talk 18:00, 9 March 2011 (UTC)[reply]

Please keep in mind that a lot of the overall byte-size is formatting and navigation templates, which shouldn't count. Using Bawolff's character count gadget, I estimated the actual content available to read to be at nine kilobytes. Tempodivalse [talk] 18:24, 9 March 2011 (UTC)[reply]

I don't know if it is a stylistic thing or not, and I'd welcome further input, but I found my nutshell easier to work through. That, broken up, might be somewhat better wording. So, let's see what people make of the two side-by-side for accessibility. --Brian McNeil / ^talk 18:49, 9 March 2011 (UTC)[reply]

I think both methods do the job reasonably well, just in different ways. We need outside opinions on which is better and/or what could be done to improve them. I'll admit your version covers more details for a more complete article (e.g. pull quotes, pipe-trick), while mine was stripped to the absolute basics in the interests of avoiding TLDR. (I suppose I could cut out the introductory section, since it isn't directly related to writing an article, but I felt it was necessary to give a little reminder of the project mission.) Tempodivalse [talk] 19:02, 9 March 2011 (UTC)[reply]

Contributor statistics

The wiki contributor statistics for January are now out and available here, and even I, expecting a bad result, was surprised:

New wikireporters (users who edited at least 10 times since they arrived): 3. Second lowest number ever for one month.
Active wikireporters (who contributed 5 times or more in this month): 29. Lowest since November '04 (!), when the project was started.
Very active wikireporters (who contributed 100 times or more in this month): 5. Same as last November, then you have to go back to late 2004 to see those kind of numbers.
New articles per day: 2. Record low since the November '04 (and that wasn't even a full month).
Edits per month: 18k. Lowest ever in a month, by 3k.

There shouldn't be any question now that we're headed on a downward spiral. We need to start looking at how to get our userbase back in a broader sense, not just the review process (although that could be a good part of the reason). February stats should be available shortly as well, for comparison. Tempodivalse [talk] 16:35, 10 March 2011 (UTC)[reply]

Update: February stats are now in, and they're not any better; indeed, they're about on par with January stats (same number of "new" and "very active" reporters, still two articles a day, a very insignificant rise in edits per month). Tempodivalse [talk] 21:29, 10 March 2011 (UTC)[reply]

I have suspected since mid-December that we are actually floating a little below a critical threshold of reviewer availability. Rather abruptly we had much higher output — for a little while, until people disappeared for the holidays. I've been figuring that getting over that threshold provides the fuel, and then with a spark to ignite things, they move. Then, whether the feedback loop is negative or positive depends on our ability to retain and train up first-time authors (though I misdoubt more pages for newcomers is what's needed). --Pi zero (talk) 07:32, 11 March 2011 (UTC)[reply]

We've actually been below this "threshold" since September, judging from the graphs; that would be around the mass-retiring. There is an especially significant drop in edits per month (for the last four months, they've been half of previous levels), and a sharp 60-75% drop in number of new users contributing, held for the last half year. The Christmas spike only provided a slight boost (which still wasn't nearly enough to get things close to pre-September levels).

Suggestion: Form a plan of action to revive the project. This thread has veered off topic from its original purpose, so let's abandon it for now. Instead, restart the entire conversation in a new thread, focussed primarily on expanding the userbase. View and analyse the graphs I linked to above; get the entire community involved and come up with ideas to revive Wikinews (i.e., throw stuff until something sticks). We need to do something, soon. In its current state this project is failing. Tempodivalse [talk] 16:09, 11 March 2011 (UTC)[reply]

It seems my point may have been quite lost, about the incident in December. In no way did I suggest the phenomenon would have had a significant impact on the month; rather, in actually observing the phenomenon when it happened, it was clear that something had briefly slipped into a different mode of behavior than it had been in recently, and I suggested that brief change of mode offers insights into the underlying dynamics of the system. I wouldn't expect the effect to be much visible in the monthly stats; you'd miss the trees for the forest. It is visible (though lacking the immediacy of seeing it live) in the list of articles by day. --Pi zero (talk) 19:39, 11 March 2011 (UTC)[reply]

There are ongoing discussions relating to making it possible to increase the userbase. Posting statistical evidence for an already known problem does not solve such.

I don't want to try and rehash such here, but will briefly lay out some points:

The, perhaps ill-judged, poll to de-reviewer Jimbo highlights that there is an issue lingering from the chaos of FlaggedRevs initial introduction.
Reviewer, for the time being, should be reigned back to those with local expertise.
A formal review should not be a barrier to "seemingly published". (i.e. listed on the front page.)
Point 2 is critical in that the bar at which contributors' work appears on the front page is lowered.

To try and sum up, a 'carrot and stick' approach is required. The project cannot roll back to free-for-all self-publish. To me, and others who care about their work being viewed as credible and trustworthy, the review process is a must. To new contributors, there must be a "shallow end of the pool" that hooks them into contributing then pushes their standards up to a more formally reviewed level.

What I think is needed is technically possible; it will need a lot of policy work too, possibly some gadget work. I have not time now to fully expound on this, but will as time permits. I would say that people who've no experience pre-FlaggedRevs should look to the edit wars before they joined. That will rear its head again, but an argumentative community that shares the project's broad objectives would be more healthy. --Brian McNeil / ^talk 23:11, 11 March 2011 (UTC)[reply]

My understanding from speaking to another contributor is that the project has already rolled back once to a free for all self publish, I believe, when Wikinews had a review process before which got dropped. Frankly we need to stop fannying around, and pick one or the other. Either we review or we don't. Personally, I believe we should drop review, period, and get the fuck on with being a news site instead of a bunch of panicked monkeys running around scared out of our bollocks in case we (oh heaven forbid) publish something GNews won't like. Dump it, screw it, and piss on it. We run this site, we make the rules. Google News doesn't. If we have a review process, it should be because we want a review process, not because someone else does. BarkingFish (talk) 04:21, 13 March 2011 (UTC)[reply]

We're building a concept that's better than either extreme, which is a sufficient reason in itself not to choose either extreme. --Pi zero (talk) 21:14, 13 March 2011 (UTC)[reply]

License question

I just copied Template:Copied to here from Wikipedia which I guess is unacceptable. So I guess I have to obtain permission from each and every contributor to that template. Any reword is going to be sub-par. Just wondering if I on the right track. Also there is no inter-wikinews attribution policy here. If I copy something from within Wikinews onto another Wikinews article do I even need this template or is an edit summary attributing the author good enough? The attribute template was only added to Wikipedia in June 2009 so maybe it is just not that important. Marcus Qwertyus (talk) 06:05, 11 March 2011 (UTC)[reply]

If you use material from an earlier Wikinews article in a followup, you list it under related news. It, in effect, is a source for the more recent report. I think you'll find that renders the somewhat encyclopedic template useless on this project. --Brian McNeil / ^talk 08:49, 11 March 2011 (UTC)[reply]

Copying from another Wikinews should give credit in at least the edit summary (and possibly on the template docs), just to be nice more than anything else. Copying from Wikipedia is technically not allowed, although there are some exceptions that have been silently ignored. Bawolff ☺☻ 17:57, 11 March 2011 (UTC)[reply]

<nod> The CC-by license requires a link back to the original source or other acknowledgement. If you include a link back to the earlier story under the L2 header Related news then you do not need any other template or acknowledgement when copying. (This is especially useful for 'backgrounder' paragraphs.) - Amgine | t 18:01, 11 March 2011 (UTC)[reply]

Note, we already have equivelents to wikipedia's copy like {{fork}} {{Translated Wikinews}}, etc. See category:Citation templates, some of which apply to this situation. (Earlier I thought you meant just copying templates in general). Bawolff ☺☻ 18:09, 11 March 2011 (UTC)[reply]

Amgine has expanded on my point; the imported template should now be nommed for deletion. Copying a relevant paragraph or two into a followup is commonplace in mainstream media. On Wikinews we already have mechanisms to ensure traceability is maintained. --Brian McNeil / ^talk 23:24, 11 March 2011 (UTC)[reply]

Revocation of reviewer

As I'm sure you're all aware, I opened a request for de-reviewer on User:Jimbo Wales a couple of days ago. Judging by the discussion on-wiki and on IRC, it is apparent that some policy needs to be made (whether to say the right is permanent or not). The facts as I understand them:

We currently have approximately 150 reviewers.
Reviewers are the most important part of our pseudo-CMS we have on Wikinews.
Reviewers can submit news to news aggregators, censor pages from appearing to a passer-by, and publish articles.
Inappropriately published articles can tarnish our reputation massively, so all reviewers must be up-to-date with current policy.
Easy Peer Review (abbreviated to EzPR, or EPR, depending on one's pronouncation of the last letter of the alphabet) has been around since 2007, and became mandatory at some point after that.
Before community requests had to be made for reviewer policy, all one had to do is request the right from an admin, much like rollback on English Wikipedia. During this time period, some people got the right without even asking for it.
Some reviewers have never used the right, ever, in any form. Other users got the right purely for its autoreview flag.
Autoreview is now obscelescent.

tl;dr
Reviewers have been around since before EzPR was introduced; they have no concept of current policy and many have not been through a formal request for reviewer. Options include leaving everything as it is, revoking rights of users that haven't reviewed anything ever (with varying definitions of "reviewing"), or revoking users on an activity basis.

I've trawled through Special:ListUsers and Special:AdvancedReviewLog to come up with some statistics on our reviewers. Several, as mentioned above, have never used the review right; others have not used the manual review. Stemming from the idea that "if they wouldn't pass an RfP today, they shouldn't have the right", the following is a list of criteria for dereviewer, ordered, as I see it, least extreme first. An exception should be made for IPBE users (as they are mainly alts of actual reviewers, which is uncontroversial):

ad vitam aut culpam: In essence, the "status quo" we have now — once you have the reviewer right, it's yours until you make a mistake, upon which a request for de-reviewer ensues, or you resign. Keeping the status quo sets a precedent, and instantly skyrockets the bar for reviewer, as many mistakes are required in practice for the de-reviewer process to start. However, it's the easiest thing to do, as it requires little to no action on our part to implement. For my part, I believe that this is the wrong thing to do: it works fine if one assumes that all reviewers are permanently active, but if a user goes away for a long period (like many of the early reviewers), there's a danger of disassociation from current policy, which, in my opinion, should not be risked.
Remove the rights of reviewers that have never used it. If they haven't used the bit by now, chances are they never will. Brion VIBBER; Brynn; Dan100; Dev Sock 1, 2 and 3; Eloquence; Hmwith; International; Jayron32; Kingjeff; Lankiveil; MBisanz; Rschen7754; and Tomos have never sighted a revision, using neither automatic nor manual methods. There's little reason for them to add to the count at the top of Special:RecentChanges. As they have never used the right, there is no way of demonstrating that they know what they are doing (from a policy sense of view, obviously the Deputy Director of the Wikimedia Foundation, and the former CTO both know what they are doing from a technical standpoint). If they can't demonstrate their knowledge of the tool, they would never pass an WN:FR/RFP today. The users affected are highlighted with a red flag on my statistics page.
Remove the rights of reviewers that have never really used it. Basically the same thing as above, but with a larger scope. As some users have technically 'used' the auto-review feature, they haven't used it for very much: often an edit, or two, or perhaps only a day's worth of edits: in any case, not something that requires the group (as it has little impact on the review queue). This would encompass all of the above users, in addition to AstroHurricane-007 (used for just two days); Aude (used for a single day); Borofkin, GW Simulations, Howie-test, Jimbo Wales, Shoone, and White Cat (used for a single edit); and Soapy (used for two edits).
Remove the rights of reviewers without a manual review. As the autoreview right is no longer associated with the reviewer usergroup, there is no reason to keep these users as reviewers. If they aren't going to use it, why should they have it? Note that removing the reviewer group from a user will not unsight any of their auto-reviews. This would affect the users mentioned above, with the addition of: Cometstyles, Daniel, EVula, NicholasTurnbull, Nzgabriel, Redirect fixer (which is obsolete anyway), and WNewsReporter.
Remove the rights of reviewers that have not used E(z)PR. As EzPR has become policy, users that have not used EzPR do not require rights: they are either so inactive that they haven't reviewed since EzPR became policy (likely), or they are reviewing improperly (unlikely). This is my preferred option, as it eliminates all users that haven't used the tool, as well as those who haven't reviewed recently. Taking this route would leave approximately sixty-seven reviewers.
Revoking rights of users inactive for over two years. I'm not sure about this idea, but it has benefits in the fact that the same policy is applicable for an infinite time in the future. I haven't done any digging into this, so there's not much else I can say about it.

As for applying the policy in future, there are two options:

a) Any time a major policy shift happens (such as the implementation of a new review system, or a distinct raising of the standards required for publication), an audit, such as this, should take place, removing the rights of inactive users after a grace period of six months to two years.

b) Removing the reviewer right of all that are inactive over a two to three year period (not as favourable, perhaps?)

That's all the cards I can think of on the table; but there may be a few scattered on the floor that I've missed. Hopefully I'll stimulate some discussion. It's my firm belief that we need to reform lots of things about Wikinews — this is a good starting point. To paraphrase someone on IRC, reviewing must be a transparent process. Let's try to make it as simple as possible (from a new user's point of view), by removing the users that make it hard to find the ones that are actually responsible for maintaining standards. — μ 19:53, 2 March 2011 (UTC)[reply]

section break (Revocation of reviewer)

I say 2-3. This isn't really that big of a deal. The rights are easily reinstated. If anyone complains about it I am sure they can be given back. Not to mention the process is not all to complicated to request the rights again. DragonFire1024 (Talk to the Dragon) 20:05, 2 March 2011 (UTC)[reply]

My thoughts:

I approve of option 4.
Not yet decided on option 5. When I applied for the bit (after being gently nudged in that direction), I didn't consider myself ready yet to do full reviews —iirc I claimed only to know when not to act— and I did my first full review a little over a month later (my second a month after that, and my third almost three months after that).
I suggest a stronger version of option 6: instead of two years, make it one year. It's not difficult for a returning user to apply for re-grant, and xyr application is an occasion for reaffirming ties with the community and being brought up to speed on whatever may have changed in xyr absence.
One stat you don't seem to have tabulated is who was granted the bit without a community discussion (understandably, as it's a pain to reconstruct). Some of those aren't ancient; I know the practice kept going on sporadically long after standards had solidified, and for all I know it still goes on today.

--Pi zero (talk) 21:22, 2 March 2011 (UTC)[reply]

I tend to favour going through and actioning almost all the above as-is. It does raise the question: why doesn't MW auto-remove unused rights after an instal-defined time? --Brian McNeil / ^talk 00:09, 3 March 2011 (UTC)[reply]

There's no real reason for MediaWiki to support such a feature; there's not really a strong use case to justify the amount of work it'd take to implement. — μ 00:41, 3 March 2011 (UTC)[reply]

For the average wiki, it'd be weird to have auto-revoke rights, so it'd definitely not something you'd want on by default. Additionally if you had mediawiki automatically revoke say admin rights after a year, and had no one touch your wiki for a year, that'd be bad. But, It might not be as hard as you think to implement though, given we already support auto-promoting people [could do similar checks] (I think, haven't looked at code whatsoever, could be totally wrong) We also record the timestamp the user last done anything [i think thats what user_touched corresponds to anyway]. Bawolff ☺☻ 02:05, 3 March 2011 (UTC)[reply]

Back to actual issue at hand. I don't have that strong an opinion, I lean towards either keeping status quo (inactive reviewers don't really bother me), but I'm also ok with removing the rights if they havn't done any reviewer related actions in say a year (Thats easy peer review or sighting random pages like templates. Throwing in general edit activity into determining if they lose the right might be nice too). I don't like the idea of removing people who sight stuff but haven't used EzPR review recently. Bawolff ☺☻ 02:05, 3 March 2011 (UTC)[reply]

p.s. Some of those accounts (howie-test and the dev sock one's) were set up to let some usability initiative folks test the review process as implemented at Wikinews (I think; brianmc knows details if i recall). Since they're not real people, we can remove the rights or not remove as we see fit with less controversy. Bawolff ☺☻ 02:08, 3 March 2011 (UTC)[reply]

Do it. If they ever become active again, they could ask for the right again, but there's no need to have those persons just increase the number of reviewers which, most people know isn't that high. --Diego Grez ^{return fire} 15:13, 4 March 2011 (UTC)[reply]

I'd like to make sure that users have to file another WN:FR/RFP to regain their rights, especially those that didn't go through one in the first place (perhaps the introduction of EPR is a good cutoff for policy). — μ 17:06, 4 March 2011 (UTC)[reply]

Agreed. The formal process is key; besides simply ensuring the individual is assessed by the community, the formal process is (as I put it above re inactivity) "an occasion for reaffirming ties with the community and being brought up to speed". --Pi zero (talk) 04:42, 6 March 2011 (UTC)[reply]

2-3 and 6 strike me as the good options. Especially 6. Blood Red Sandman ^{(Talk) (Contribs)} 20:38, 5 March 2011 (UTC)[reply]

second section break (Revocation of reviewer)

Based on the comments above, perhaps we can agree on a specific set of measures. I propose this set:

Now: Remove the rights of reviewers that have never used it.

Brion VIBBER; Brynn; Dan100; Dev Sock 1, 2 and 3; Eloquence; Hmwith; International; Jayron32; Kingjeff; Lankiveil; MBisanz; Rschen7754; and Tomos.

Now: Remove the rights of reviewers that have never really used it.

AstroHurricane-007; Aude; Borofkin, GW Simulations, Howie-test, Jimbo Wales, Shoone, and White Cat; and Soapy.

Now and hereafter: Revoke rights of users inactive for over a year (twelve months).
When the bit has been removed for any of these reasons, a formal RFP process is required to regrant the bit.

As I'd mentioned above, the formal RFP process serves social, informational, and technical functions.

This has been miscellaneous clutter on our to-do list for far too long. --Pi zero (talk) 16:09, 12 March 2011 (UTC)[reply]

(Note: looks like I slipped on the length of the inactivity; I didn't mean to overstep the sense of the earlier discussion. Sorry about that. Having written it I'll leave it stable, so comments don't have to deal with a moving target.) --Pi zero (talk) 16:20, 12 March 2011 (UTC)[reply]

A lot of the users you're proposing to de-flag are also admins, and there are also some users who received the status "by the rules" at WN:RFP. I oppose removing the rights of these users, but hold no strong opinion on the others. Tempodivalse [talk] 16:26, 12 March 2011 (UTC)[reply]

Support removal from all listed. Get it over and done with. --Brian McNeil / ^talk 19:42, 12 March 2011 (UTC)[reply]
Support making explicit my support as proposer of this specific set of measures. --Pi zero (talk) 14:26, 14 March 2011 (UTC)[reply]

Request that you add an option (migrated from user talk page)

I think your presentation of the options regarding reviewer rights is lacking at least one important option: give the reviewer right freely to anyone who has achieved a flag status of Admin on any Wikimedia Foundation project, along with a request that they not use it until they have read through a brief tutorial of how to use it. I think the direction you are trying to take this is the wrong direction, and generally agree with Amgine's stated view that "The review process as implemented on en.Wikinews is strangling the production and publication process, and more importantly is preventing growth of the community."

I can tell you my reaction to your proposal: it feels rude and unfriendly. It did not make me want to come and contribute to Wikinews. In my view, moving in the direction you are trying to take things is going to be the final death knell for an already too-small community.

I would have added this comment to the policy page where you made your proposal, but of course I can't: that page is protected. Yet another example of exclusionary policy killing the community! :) Please rethink this.--Jimbo Wales (talk) 16:46, 17 March 2011 (UTC)[reply]

Mr Wales, which page were you trying to edit from? WN:WC is full-protected because it simply transcludes the subpages. Perhaps you could try editing from the appropriate subpage instead (WN:WC/P). Tempodivalse [talk] 18:07, 17 March 2011 (UTC)[reply]

Jimbo:

Your unfamiliarity with the Wikinews Water cooler is symptomatic, although I agree that page should not have __NOEDITSECTION__ (and I have argued that point in the past, but the community makes these decisions.) You, and most administrators on en.WP, are not aware of how things are done on en.WN, just as en.WN administrators should not be trusted, based on their en.WN reputation alone, to know the policies and requirements for Good Articles and be allowed to mark articles as GA on en.WP. I don't think you would seriously argue all en.WN admins should be able to mark en.WP articles as GA or FA, yet you're suggesting a very similar level of trust must be extended to en.WP. If you stop and think about it, that is fairly rude/insulting to this entire project and its contributors.

We are in the process of discussing changes to how the Review policy would be implemented; we could use some help getting the Google News Site Map extension reviewed so we can cut back on a lot of the instruction creep that makes review process such a hassle, and that would make the Reviewer role much less a hurdle here. You might want to join the discuss about the templates which display our published/reviewed articles.

- Amgine | t 21:41, 17 March 2011 (UTC)[reply]

Authentication of a YouTube posting

Twice today, I've encountered queued articles that use as a source a YouTube page claiming affiliation with a reputable news source. For example,

http://www.youtube.com/watch?v=UuYT4YSPyUU

by user

http://www.youtube.com/user/itnnews

claims to be ITN, a plausible claim that I tried to verify by finding a link from http://itn.co.uk/, but couldn't.

How ought one to handle this sort of thing? --Pi zero (talk) 00:26, 8 March 2011 (UTC)[reply]

One possibility is to try and see if the link can be found in GNews, who now allow sources to release YouTube videos and have them listed alongside traditional articles. If it's listed there as ITN, it's verified to be them. Blood Red Sandman ^{(Talk) (Contribs)} 00:28, 8 March 2011 (UTC)[reply]

Handy technique.

It looks as if that YouTube video is an unauthorized copy of ITN footage with the leading paid advertisement stripped off. --Pi zero (talk) 02:07, 8 March 2011 (UTC)[reply]

On that basis, I'd say the video should not be used (copyvio) - if there is an "official" ITN YouTube channel that should be used instead. --Brian McNeil / ^talk 13:10, 8 March 2011 (UTC)[reply]

http://www.youtube.com/user/itnnews looks like it IS the official channel to me. Sfan00 IMG (talk) 17:44, 18 March 2011 (UTC)[reply]

Making contributing to Wikinews less strict

In the wake of numerous, overly verbose, discussions I am proposing that articles not subject to the current full formal review may once again feature on the main page.

In a nutshell, a more well-developed version of {{Main stories}} would replace the current DPL template of formally reviewed articles.

There are needed tweaks to the template, and associated CSS. Plus, some consideration of the workflow with such. I will lay out the majority of such on the template's talk page. --Brian McNeil / ^talk 10:45, 13 March 2011 (UTC)[reply]

So you're suggesting that we have 2 tiers of articles? Factchecked, peer reviewed articles, and "free for all" articles?

If that's what you're proposing, I think that I could get behind that, if only to end the current impasse. Several news sites out there do something similar, where they have "real" news articles, and then a section below that with blogs, etc. We could do the same thing, with peer reviewed articles promininately displayed, and non peer reviewed articles placed in a list further down the page. Gopher65_talk 21:00, 20 March 2011 (UTC)[reply]

Two tiered review process

Expanding on my above comment, here's what I'd prefer over what was described above:

What I'd prefer however would be a two tiered PR system (flagged revs already supports multiple tiers, so it wouldn't be an issue from a technical standpoint). A first tier review would basically be nothing but fixing formatting (add cats, add infoboxes, etc). That's fast to do, taking only a minute or two even for exceptionally long articles. These articles would be the current equivalent of "sighted". The ability to sight articles could be given at admin discretion ("oh, you've been on the project for 3 hours and written an article that doesn't look tooooooo bad? Here! Have a tier 1 reviewer flag!").

Full reviewed articles would be done just like they are now using the current peer reviewed system, but with the addition that they'd use the presently unused second tier of the Flagged Revisions system.

Articles would then be laid out just as described above, with two separate sections, one section for "real" news articles, and one section for un-fact/copychecked articles.

Google News: Google News would have to directed toward either a sitemap, or simply redirected to the {{Main stories}} template, since that's where all the properly peer reviewed articles would be listed (dunno if Google is willing to do that or not, but if they are that would be an easy fix). That way we wouldn't be in danger of having factually incorrect articles listed on Google News, and potentially losing our listing. Gopher65_talk 21:00, 20 March 2011 (UTC)[reply]

Adding:

The reason I suggest a two tiered system is twofold:

1) Currently copy/factchecking is the bottleneck in the peer review process. If we eliminate that from the first tier of review, it would remove the bottleneck.

2) Completely removing the necessity of a full peer review would mean that we'd be publishing a lot of total trash. A two tiered system would mean that our trash publications would be *clearly* laid out for the reader to see, so that they'd have less expectations of our trashy articles than they would of our real articles.

I don't know about you, but I give any site I go to two chances. If I hit a trashy article, that's strike one. If I hit another useless article, I then decide that the site in question is worthless, and I never go back. There are plenty of sites to choose from, so it's no loss to me - but it is a loss to them. Gopher65_talk 21:10, 20 March 2011 (UTC)[reply]

I suggest making this work calls for "late publish" (an idea suggested almost two years ago (here)).

Why: Expanding contributor base needs to translate into expanding top-tier output, and it only translates if contributors of lower-tier articles always aspire to achieve top-tier — it's not about whether all articles achieve it, but that they aspire to it. Contributors strive for top-tier quality, by striving they learn to produce it, and our top-tier output increases. The aspiration shouldn't stop when the striving has taken too long so that the article passes outside its freshness horizon, hence "late publish": if an article meets all criteria for peer review except freshness, it can be late-published.

I suggest these specifics:

Requirements

Must have been started within a week of the news event. (If people dislike this or want certain classes of exceptions, I don't feel strongly.)
Sources cannot be past the freshness horizon of the story (seven days from event, three days from most recent information come to light).

Outcome

Date when published will be the date of the freshness horizon, rather than the date of review.
Doesn't get fed to GNews etc.
If it appears on the main page, it's listed as upper-tier (despite the lack of feed).
It goes into the archive as upper-tier.

--Pi zero (talk) 22:20, 20 March 2011 (UTC)[reply]

Why is this still being fiddled with like this? We don't have late publish - not just because of staleness - but because you're writing with hindsight. Such content, unsurprisingly, belongs In The Other Place. What was a seemingly straightforward solution to a key issue with Wikinews at the moment has been talked to death. J.F.D.I. --Brian McNeil / ^talk 23:02, 20 March 2011 (UTC)[reply]

But what, out of the multitude of options, should we do? One cannot just do it without knowing what it is to do. — μ 23:04, 20 March 2011 (UTC)[reply]

"Multitude of options"? That's not the case. Right now, we would have to use some sort of kludge to get non-formally-reviewed articles on the front page. That is simple, it is just the case that some people want to make this overly bureaucratic. That's wrong, and that's exactly why there is a push to have a look at what could be done. As far as I'm concerned, it should include the ability to self-publish. People can then just get used to the edit wars. If Google hadn't smothered Usenet, I'd be suggesting numerous of the more conservative contributors spend some time there, then come back and take a fresh look at Wikinews. --Brian McNeil / ^talk 23:32, 20 March 2011 (UTC)[reply]

Nethertheless, we still don't have a properly defined "what do we do"? If we have decided that we want to get non-formally-reviewed article on the Main Page, we still need to define when an article can have a stint on the Main Page. Edit wars on the Main Page are, of course, unacceptable. That's what sandboxing is for. — μ 23:39, 20 March 2011 (UTC)[reply]

I'm not referring to edit wars on the main page, but over whether or not something is suitable for publication in any way. --Brian McNeil / ^talk 23:47, 20 March 2011 (UTC)[reply]

A practical question. (The idea is to fail to shoot down the proposal.)

You've given us to understand the unreviewed flow is contentious (however exactly it's supposed to work).
Distracting reviewers slows review. Moreover, the peer review system has a demonstrated threshold of reviewer availability, below which it becomes almost completely dysfunctional — we're only recently having a sustained run slightly over that threshold after several months almost entirely below it.
So, if the unreviewed flow and peer review system are combined in a single system, why would that not cream the peer review system, by putting it below the threshold and keeping it there?

Is there some evidence from pre-FR to support the optimistic view on this? I've heard there was some form or other of peer review before the current regime (never heard what form), but I hadn't heard it coexisted with unreviewed workflow. --Pi zero (talk) 07:52, 21 March 2011 (UTC)[reply]

┌─────────────┘
Of course the non-formally reviewed workflow is contentious. Crap will need "unpublished", i.e. removed from the front page, disputed in some manner or other.

The "in-the-beginning" review process was a stab at what we've got now, but without the means to enforce it.

Self-publish was fairly common prior to the implementation of flagged revisions, and there were few trainwrecks made it onto the front page. By-and-large, someone would put together an article, mark it as ready, then an hour or so later get tired of waiting and simply publsh it themselves. I see no reason not to reintroduce that. If people don't want to have that happen, they'll need to read proposed articles and if there's a problem fix it or flag it. --Brian McNeil / ^talk 09:52, 21 March 2011 (UTC)[reply]

That's interesting history, and seems to suggest an answer to my peripheral followup: that no, there is no historical precedent that bears on my central question. You haven't addressed the central question itself, though. Sorry if there was any unclarity in the structure of my post. The first two bullets (without question marks) are key background for the question; the third bullet (the one with a question mark) is the central question. --Pi zero (talk) 10:25, 21 March 2011 (UTC)[reply]

Then, ask questions and omit needless words. Of course review will still be important. People will want their work pushed to GNews and distributed via the social networking tools. --Brian McNeil / ^talk 10:31, 21 March 2011 (UTC)[reply]

I used no needless words. (I've no objection to being proven wrong, if that motivates you to read my post carefully.) And although "Of course review will still be important..." is vaguely relevant to an issue I raised elsewhere, as an answer to my current question it is cryptic. --Pi zero (talk) 11:37, 21 March 2011 (UTC)[reply]

Sniper alley

Let's drop the nonsense, and the excess verbiage.

MC8 proposes an ideal item below: Tell people when they may self-publish. Beyond that, people will be unhappy their work is not going out to Google, Facebook, and so on. That was the very reason we pushed for FR and implemented a review process. Ask around, you'll get little or no argument that we've a perhaps overly-burdensome raft of policies; this needs to be simple, it needs to offer quick, hopefully positive, feedback. Then people's standards are pushed up; it becomes easier to review.

You seem to have missed a bad thing creeping back in here; people throwing every semi-relevant source they find at something they'd like published. Pedia-thinking. You're applying "Pedia thinking" to this proposal, you've talked the legs off it Pi, and it is proving rather difficult to make it walk now. Stop over-analysing and just try things. --Brian McNeil / ^talk 11:52, 21 March 2011 (UTC)[reply]

Re "Pedia thinking". Sorry, that's bullshit. Forging ahead differs from charging blindfolded into a minefield. And what it's looked like(!) from my side: I haven't been adding unnecessary crap; you have. I've crafted well-thought-out lean posts, and you've wasted space and time by not reading what I wrote. As with my anticipation four days earlier of your above objection to late publish.

I've asked a question of minefield class. About full stall-out of PR, the fail we've just survived that took months to restart (knock wood). It's plausibly suggested, unreviewed workflow plus PR could cause PR full stall; so why wouldn't it happen. Needs an answer; if it's from me and/or trivial, so I look silly, great! As long as looking silly gets me the damn answer. --Pi zero (talk) 15:09, 21 March 2011 (UTC)[reply]

You had your answer in one of Tempo's remarks: the error rate was not significantly higher. The "stall" may well recur, but article count won't go up if we're dicking about as to ways to lower the bar in preference to doing something. So, go ahead: post another thesis. It isn't a solution, or even a proposal. --Brian McNeil / ^talk 01:55, 22 March 2011 (UTC)[reply]

Interesting assessment re stall. Could have been clearer in < 1/4 the words, by omitting BS rant and Tempo's over-interpretation.

Answer this (likely far under 40 words if you omit rant):

How should unreviewed-archive be determined? (Vote? Time? (3 days? 7? 4?? From event? creation?))

--Pi zero (talk) 14:30, 22 March 2011 (UTC)[reply]

Notice device

{{#ifexpr: {{CURRENTTIMESTAMP}} - {{REVISIONTIMESTAMP}} > 60 | This article is eligible for self-publication to the Main Page. | Please wait for an independent editor to publish this article to the Main Page. }}

— μ 10:59, 21 March 2011 (UTC)[reply]

Nice. Simple, effective. And, in a language most people understand. --Brian McNeil / ^talk 11:52, 21 March 2011 (UTC)[reply]
If you don't mind a minor but very important modification:
{{#ifexpr: {{CURRENTTIMESTAMP}} - {{REVISIONTIMESTAMP}} > 60 | {{publish}} | {{Instant review requested}} }}

Put it in a template, say {{Ready}} - Amgine | t 02:23, 22 March 2011 (UTC)[reply]
Current plan calls that template {{published-unreviewed}}. Ideally we'd also call the other {{published-peer-reviewed}} or suchlike, and not use the name {{published}} at all.
{{#ifexpr: {{CURRENTTIMESTAMP}} - {{REVISIONTIMESTAMP}} > 60 | {{published-unreviewed}} | {{Instant review requested}} }}

--Pi zero (talk) 14:57, 22 March 2011 (UTC)[reply]
Use simple, unambiguous language. Avoid surprises. Intuitive, ergonomic choices should be preferred. Precise, hiearchical language and jargon are wonderful in programming and science, in many settings, but not in the interface with the public. - Amgine | t 15:24, 22 March 2011 (UTC)[reply]
Ideally, yes; my "ideal" scenario didn't go far enough. The simpler name would go to the unreviewed-publish rather than the peer-reviewed-publish; the former is apt to be manually edited, while the latter is pretty much always applied by automation. A speed bump is thousands of archived articles that use the simpler name for the peer-reviewed-publish one. --Pi zero (talk) 16:16, 22 March 2011 (UTC)[reply]

K.I.S.S. (Keep It Simple S-----)

Decide: (a) Use 2 levels of flagged revisions, or (b) Don't.
Develop an appropriate template for use on the front page.
Replace latest news with new template.
See how things go from there.

There is no need for endless discussion on point 1, such is stalling things dreadfully. Don't "invent" needless complexity. --Brian McNeil / ^talk 23:47, 20 March 2011 (UTC)[reply]

I endorse implementation. theMONO 00:18, 21 March 2011 (UTC) edited by MC8[reply]

Wikinews:Water cooler/policy/archives/2011/March

Contents

Wikinews:Guidelines for class projects

Re-opening worm of cans: Radically alter or dump the develop-review-publish process

Three possible options

Mission question

Review process issues

Questions to ask yourself

Wiki War-Zone

Closing remarks

Semi-arbitrary break

My hovercraft is full of eels

"Something must be done; this is 'something', let's do it."

BBBBreak

Contributor statistics

License question

Revocation of reviewer

section break (Revocation of reviewer)

second section break (Revocation of reviewer)

Request that you add an option (migrated from user talk page)

Authentication of a YouTube posting

Making contributing to Wikinews less strict

Two tiered review process

Sniper alley

Notice device

K.I.S.S. (Keep It Simple S-----)

Navigation menu

Wikinews:Water cooler/policy/archives/2011/March

Wikinews:Guidelines for class projects

Re-opening worm of cans: Radically alter or dump the develop-review-publish process

Three possible options

Mission question

Review process issues

Questions to ask yourself

Wiki War-Zone

Closing remarks

Semi-arbitrary break

My hovercraft is full of eels

"Something must be done; this is 'something', let's do it."

BBBBreak

Contributor statistics

License question

Revocation of reviewer

section break (Revocation of reviewer)

second section break (Revocation of reviewer)

Request that you add an option (migrated from user talk page)

Authentication of a YouTube posting

Making contributing to Wikinews less strict

Two tiered review process

Sniper alley

Notice device

K.I.S.S. (Keep It Simple S-----)

Navigation menu

Search