Wikinews:Water cooler/proposals/archives/2009/September

From Wikinews, the free news source you can write!
Jump to navigation Jump to search


Licencing update on the 'Pedia! Worth us taking a step ?

Hey everyone, for those that haven't followed the link in the banner An overwhelming number of users have voted for migrating the Pedia to CC-By-Sa. More importantly I was well pleased to see the board has decided to implement the change starting in June! I'd been hoping for something along those lines for a while, because I do see a great opportunity for us as well. Yes I know we currently have the CC-By licence - thus the situation that we can only feed into the Pedia, and not vice versa hasn't changed. See here for a short semi exchange between me and Bawolff on that.

OK to get to the point: What do people think: Does this raise the question for us whether we should change our licence so as to make content sharing possible both ways between us and the Pedia? . I realise that for one, that's not for us alone to decide - however I do think the english Wikinews has a strong leadership role, and if we we're to favor this, chances are we might get others to share our views. Also, of course, our current licence was chosen for a reason - however, I do think that if the Pedia had been using CC-BY-SA at the time of our founding, the decision may have been made in a different direction. So! I'd be very interested in your opinions! Regards Sean Heron (talk) 23:12, 21 May 2009 (UTC) P.S. Woot woot! Licence change - party time![reply]

Actually, that poll covers "wikis operated by the WMF" which is not merely WP, but presumably includes WN. Therefore the licencing update is already set to affect English WN. To be fair, all WMF wikis were invited to vote on this. Next steps as described on the results page are imminent final revisions to proposed terms of use. DL+1613 (talk) 23:01, 30 May 2009 (UTC)[reply]
As far as Wikinews goes, it only covers local material already under GFDL. We would need a separate vote to migrate to CC-BY-SA, and it would not suit how we want to share our material. --Brian McNeil / talk 23:06, 30 May 2009 (UTC)[reply]
Well that's where I'm saying there might be different opinions - I don't see the problem with giving attribution through a link for example (though yes I realise, following the discussions on the licence change that may be in legally murky waters/depend on interpretation of the CC-by-sa licence). Regards Sean Heron (talk) 17:34, 1 June 2009 (UTC)[reply]
I know this is an old thread, but Wikinews moved to the CC-By license in 2005. When WP moved to this license we were able to share content both ways - that is, WN can directly incorporate content from WP. Keep in mind that WP has so many more contributors that A) it's difficult to keep a breaking story current with their flood of incoming edits, B) sourcing a breaking story on WP requires a link to a specific revision to avoid later edits removing/altering the facts sourced.
It may be interesting to try an experiment or two of syncing breaking news stories from WP. It might be useful to use a bot to do so. It may be indicative to the WP project that they are not encyclopedic, but I doubt that will actually impinge. - Amgine | t 15:43, 11 September 2009 (UTC)[reply]
This does not agree with the understanding I came to discussing this. As I understand it, we cannot copy from Wikipedia, but they can copy from us. --Brian McNeil / talk 21:30, 11 September 2009 (UTC)[reply]
That *was* true, until this past June when they became CC-by like Wikinews. Now we're effectively under the same license (and btw: I talked with Mindspillage about WN shifting to 3.0, and she thinks it would be no problem if the project decided to do so - no license upgrade problems.) - Amgine | t 22:10, 11 September 2009 (UTC)[reply]

Editprotected user group

I know this has been brought up before, but I'd like to suggest that we have a new user group installed here - one that can edit protected pages, but has no other of the admin privileges. I don't think this should be hard to implement - all a developer has to do is to make a new user group with the same parameters as a regular user in the database, except with "editprotected=true" instead of "=false". Such a user group could be very useful, especially for trusted non-admin users, who when wanting to make changes to archived articles would not have to leave masses of {{editprotected}} requests. Thoughts? Tempodivalse [talk]

Comment If there is someone that wants this ability and is invested enough into the Wikinews community, at this point in time it would probably just be simpler to go the RFA route. Cirt (talk) 02:29, 15 August 2009 (UTC)[reply]
Comment I just feel like there are enough user groups for a community this size. The bar for getting admin is pretty low (in fact a number of admins failed the suffrage test for the arbcom vote). That's just an illustration of how easy it is to get admin which allows you to edit archived articles. How many levels of user rights should we have for such a small project? We've already tied 'rollback' to editor status, but I am not comfortable doing so with the archive. Cheers, --SVTCobra 02:45, 15 August 2009 (UTC)[reply]
Agreed. The editprotected backlog at the moment is due mainly to the request to add categories that are being contested under DR. The number of open editprotected requests is usually quite manageable. --Jcart1534 (talk) 03:07, 15 August 2009 (UTC)[reply]
We also have Bureaucrats who have been with us for under a year. The bar is getting very very low here on Wikinews. --Skenmy talk 09:00, 15 August 2009 (UTC)[reply]
I agree with Jcart1534. I've looked at those editprotected requests, and I'm not comfortable making those changes until the category discussion above is completed. So it's not that there are too many editprotected requests for us to handle, it's just that I (and the others who handle most of them as well, I'm sure) am waiting for community consensus on an issue before proceeding. Gopher65talk 15:46, 8 September 2009 (UTC)[reply]
  • Oppose It's needless. --Skenmy talk 09:00, 15 August 2009 (UTC)[reply]
  • Oppose The bar for adminship is not as high as Wikipedia, this is not needed. --Brian McNeil / talk 09:49, 15 August 2009 (UTC)[reply]
  • Oppose It's not needed. This isn't a very large community, and more user groups would cause more hassle then they're worth at this point in time. hmwithτ 16:30, 15 August 2009 (UTC)[reply]
  • Oppose as per some of the other comments, additional user groups create additional hassle and I don't see a great benefit that might result. I think if we trust someone enough to allow them to edit our archived stories then we should be able to trust them enough with the other admin rights. Adambro (talk) 15:41, 16 August 2009 (UTC)[reply]
  • Oppose per my comment, above. Cirt (talk) 18:04, 16 August 2009 (UTC)[reply]
  • Comment I don't think it is needed for this purpose. However I think it might be useful in the case of a bot who needs to edit protected pages. Currently the practice is to give them admin privs. Personally I'd feel much safer if the max damage those bots could conceivably do is to edit archived articles. Bawolff 18:16, 24 August 2009 (UTC)[reply]
  • Most active users here are already admins, so I agree that it isn't needed at this time. –Juliancolton | Talk 18:35, 24 August 2009 (UTC)[reply]
  • Support and Oppose — heh. I was going to oppose this outright, but Bawolff's comment got me thinking (danger Will Robinson! Danger!). I feel the same way about bots. Sometimes they go crazy, and I feel really uneasy having bots with full adminship. So I oppose this as a new usergroup for people, but I'd like to see a new botgroup with this ability. Most bots could then be given only one ability: the ability to edit protected pages. I'd feel much more comfortable about that than the current system. Gopher65talk 15:46, 8 September 2009 (UTC)[reply]

New users unaware of rules

One of the common problems we have here is people coming in from other Wikis and not knowing about things like WN:ARCHIVE. I propose the creation of a new template, {{notcurrent}}, and a bot set to add it to every published article two days after publication date. The template is then removed when the article is archived and protected.

The template should caution against a) Major changes b) Adding unused sources c) Adding sources dated after publication. --Brian McNeil / talk 21:24, 29 August 2009 (UTC)[reply]

Sounds like a good idea to me. –Juliancolton | Talk 21:25, 29 August 2009 (UTC)[reply]

Question Would {{notcurrent}} go at the top (where it would be noticed) or at the bottom (where it wouldn't be in the way)? --Pi zero (talk) 22:21, 29 August 2009 (UTC)[reply]

I was wondering the same, but came to the conclusion that it would most likely go at the bottom. IMO we should try to avoid notices at the top of articles whenever possible. –Juliancolton | Talk 22:38, 29 August 2009 (UTC)[reply]
  • If it goes at the top, and it's a separate template, then that's more bother to remove when archiving, isn't it?
  • Would the upper right corner be a workable place to put it, visible enough without being as disruptive as a hatnote?
  • I keep wondering if there's a way to add some logic to the {{date}} template to take care of this automatically; it certainly knows the publication date, from which it should be able to deduce the default moment to put up a notice, but I don't know of any way it can detect whether or not the article has been archived, so it wouldn't know when to take the notice back down — unless we're willing to settle for having it simply take the notice down after a fixed number of days (like seven, or a shade more to be safe).
--Pi zero (talk) 00:16, 30 August 2009 (UTC)[reply]
I know it should be possible to have the date template add some marker to the article once it's two days old, but there's a catch - I don't know how to make that conditional on the article being in the publish category. If it can be made conditional on categories there's nothing to stop use of more complex conditional code to suppress the marker when the article is archived.
The alternative is to use a bot. The bot could - as proposed - add the {{notcurrent}} template, it could even remove it when the article is archived and protected. There's also, based on your 'thinking aloud' another option. Make "notcurrent" a parameter on the {{date}} template. I would also have suggested an "archived" parameter, but I don't think you could add that to the date template and still get the archived notice at the bottom of the article. --Brian McNeil / talk 00:55, 30 August 2009 (UTC)[reply]
Yep, that's the problem. As far as I know, the only data accessible to the template branching logic are the template parameters, whether or not there exists a file with a given name, and the components of the name of the page on which the template is transcluded. It looks as if mw:Extension:DynamicPageList (third-party) might support an (expensive) call that could be used to branch on whether a file with given name belongs to a given category, but even if that's so, it's not the world we've living in now.
  • Presumably the bot would have to have admin privileges, since it would have to remove the {{notcurrent}} template after archiving.
  • I take it you're not enthused by the prospect of a {{date}} template that just automatically adds a warning after a fixed time, and then removes it again after another fixed time. That would seem to be the least technically intrusive solution, not requiring a bot to run, let alone an admin bot. Admittedly, there is a certain inflexibility in the arrangement (notwithstanding optional parameters to vary the times involved).
--Pi zero (talk) 12:52, 30 August 2009 (UTC)[reply]
For the time being, an auto-added/removed warning based on the date within the template would be fine. Unfortunately, I'm running into the usual issues on Wikipedia (See w:Template_talk:Recent_death). Some reasoned input on the discussion would be appreciated, I can find it very frustrating dealing with some of the ways people deal with things on Wikipedia. --Brian McNeil / talk 13:05, 30 August 2009 (UTC)[reply]
We could automate it with if logic inserted into an article when it is created. This would involve adding to the default article template:
{{#ifexpr: {{CURRENTTIMESTAMP}}-{{subst:CURRENTTIMESTAMP}}>200|{{Notcurrent}}|}}. This could then be manually removed when the page is archived. Dendodge T\C(en.wp) 13:27, 30 August 2009 (UTC)[reply]
This would need to be a lot more complicated to deal with articles that are published several days after creation. It's also incomprehansible code to most people - there's a good chance it will be edited out frequently. --Brian McNeil / talk 13:51, 30 August 2009 (UTC)[reply]
It may be possible to edit MediaWiki:Common.js to determine the date the article was published based on its category, then add a warning to the edit page (Wikipedia does this with pages that are sorted into Category:Living people). That way it wouldn't have to appear in the article at all and you could avoid any bot action. —Noisalt (talk) 14:03, 30 August 2009 (UTC)[reply]
Determining the date of publication would seem to require some support from elsewhere. Perhaps one could use logic within {{date}} to check whether the current date differs from the dateline by between, say, two and twelve days, and within that range add the page to Category:Not current; then the javascript could check that the page is in that category and Category:Published and not Category:Archived. --Pi zero (talk) 15:46, 30 August 2009 (UTC)[reply]
Okay, there's a variety of options up now. Someone poke Bawolff about Javascript options. I'm going to look at a few templates I could crib code from to make {{notcurrent}}. I don't think a near full-width template would be appropriate, so suggestions for something more discreet welcome.
Oh, and another Javascript idea... If referred to a main namespace Wikinews article from a page on Wikipedia, can we give some sort of specific Wikipedians read this? --Brian McNeil / talk 16:04, 30 August 2009 (UTC)[reply]
I definitely think we should go with a js option so that it is not visible when users read the page, only when they go to edit. Just like the warning that is displayed when one begins to edit an archived article. Cheers, --SVTCobra 16:54, 30 August 2009 (UTC)[reply]
Ah, now that's probably the best idea so far. A template inserted via javascript when the article is published, a published version sighted, not archived, and the current UTC date two or more days after the date of publication. --Brian McNeil / talk 17:27, 30 August 2009 (UTC)[reply]

Proposed warning

Per SVTCobra's suggestion above, Mediawiki:Common.js would require changes. The objective is to warn that no major changes should be made to an article that was not published recently.

Assuming there is some template for this, say, {{notrecent}}, then the content of that template must be inserted above the edit box when a contributor selects to edit an appropriate article. The criteria defining articles where this warning would be displayed are as follows:

  1. The article must be in the main namespace
  2. The article must be in category published
  3. The article must be in a date category
  4. The current UTC date must be two or more days after the article's date category
  5. The article must NOT be in category archived
  6. The most recently sighted revision of the article must meet all the above criteria

The last of these requirements, integration with Flagged Revisions, is not essential to this. If it is not currently possible then a separate discussion should be started to establish how FlaggedRevs status information can be made available to scripts.

I would suggest the following text, with whatever decorations are appropriate to make it stand out:


Caution! You are about to change a Wikinews article published some time ago.

Wikinews articles are a snapshot of what is known at a specific point in time. They are not meant to be encyclopedic, such content should be added to the appropriate Wikipedia articles. If you are a new contributor to Wikinews, please see the introduction.

All contributors should note the points below:

  • Do not make substantial changes to any article published two or more days ago
  • Do not add details from sources more recent than the date of the article's publication
  • Do not add unsourced material
  • Do not editorialise or add personal, or unsourced, opinion
  • If there are significant developments subsequent to publication, visit the newsroom and start a new article

How's that?--Brian McNeil / talk 18:38, 30 August 2009 (UTC)[reply]

It all looks good, and procedurally sounds good, to me. (Well, okay, if I were writing it I'd put a fullstop at the end of each bulleted item, but other than that... :-)  --Pi zero (talk) 19:26, 30 August 2009 (UTC)[reply]
Is the editnotice extension enabled here? If not, we might want to file a request at bugzilla. Dendodge T\C(en.wp) 19:32, 30 August 2009 (UTC)[reply]
Everything suggested here is possible with javascript (Combined with using the editintro option. Similar to how we do quiz edits. I'm not familiar with the editnotice extension, but we can just use edititro, which i believe is part of core ). I suggest we start making {{editintro from wikipedia}} and {{editintro notcurrent}}. (Just to clarify, the wikipedia warning would appear When editing right?. We could potentially make a Hey Wikipedian's, come look at this custom welcome appear in the sitenotice instead, but i think its better from an edit.). Bawolff 20:44, 30 August 2009 (UTC)[reply]
I have an initial version done (could probably be improved from an efficiency standpoint though.) You could test it out. Its under Experimental-editIntros in gadgets. It uses {{editintro from wikipedia}} and {{editintro notcurrent}}. Bawolff 00:47, 31 August 2009 (UTC)[reply]
I seem to get {{editintro notcurrent}} as I would expect. When should {{editintro from wikipedia}}? Oh, and it seems incompatible with the syntax highlighting gadget. --Brian McNeil / talk 01:05, 31 August 2009 (UTC)[reply]
If you click on the wikinews link at w:Simon_Dee#External_links, and then edit the wikinews article, it should come up. Currently if both the wikipedia and the not current warning apply, the not current wins out (that could be changed to give a combo message or something like that). It should be noted that the wikipedia message only comes up if you go directly from en wikipedia -> an article -> an edit page. If you got wikipedia-> an article ->browse around a bit->then edit, it won't show up. By the highlighting extension I assume you mean wikiEd? It does work in WikiEd, you just have to scroll up (wikiEd seems to scroll down automatically). Bawolff 01:33, 31 August 2009 (UTC)[reply]
p.s. This doesn't currently integrate with flagged revs. It just sees what the user sees. Thus an anon user will see the latest stable, and so will the script. OTOH a registered user will see the latest version, and so will the script. Since it is very rare that these two versions would differ in terms of {{date}} or {{published}}, i don't think this is an issue. Bawolff 01:36, 31 August 2009 (UTC)[reply]
[unindent] I changed the gadget slightly, so that its more efficient. Anyone have internet explorer to test this on? Bawolff 07:17, 31 August 2009 (UTC)[reply]
This didn't seem to work with IE8. I was editing a page from the 26th so I should have got a warning. --Brian McNeil / talk 10:15, 31 August 2009 (UTC)[reply]
Seems to work on IE7. Did you remember to log in? Bawolff 02:58, 3 September 2009 (UTC)[reply]
I found a minor little problem. If you have the option checked where a preview box appears upon first edit (I think it is the "Show preview before edit box" option), then the warning appears waaaaaaaay at the top of the page, in a place where no one would likely notice it. It should instead appear right above the edit box. Gopher65talk 16:12, 8 September 2009 (UTC)[reply]

Enable Extention:NewUserMessage

Many of us run around and welcome the newbies that show up, seems that more and more are being welcomed these days. So why don't we just skip the hard work and turn the bot on? Specifically there is mw:Extension:NewUserMessage. It will add whatever welcome message we want to all the new users. All we have to decide is A) Do we want it (The answer is yes, BTW) B) do we want wgNewUserSuppressRC on, I'd say yes (It's just another bot). C) Do we want wgNewUserMessageOnAutoCreate on (Translation: Do auto created users get welcomed), at this point I'd say why not? I think this is great for nothing else than we _know_ everyones got the message about What Wikinews is and how they can help (And how their random BS articles is going to get deleted by me and then they will be permablocked). PS. This is the same thing Commons uses. --ShakataGaNai ^_^ 18:31, 3 September 2009 (UTC)[reply]

Comments

Votes

As part of an effort to encourage more readers to write articles, I've created Wikinews:Write an article!. I suggest we make a bolded link to it on the {{Main page header}}. Thoughts? Tempodivalse [talk] 20:10, 4 September 2009 (UTC)[reply]

There already is a "Write an article for Wikinews" section on the Main Page. It is not terribly prominent, but it is there. Not sure about what is best. --SVTCobra 01:13, 5 September 2009 (UTC)[reply]
Yeah, I know we already have a box for it, but it's further down the page than most casual readers will scroll. I thought something at the top of the page would catch readers' attention more. Tempodivalse [talk] 01:17, 5 September 2009 (UTC)[reply]
Oppose While I'm not against trying to get more people involved, we need to cater to our readers too. On Wikipedia people end up at the main page because that is where you start - but then they leave ASAP. On the other hand people come to the Wikinews Main Page for a reason, they want to see the latest news. We need to keep the news the main attraction. Besides, we've already got a bold link that points to introduction which is essentially the same thing as "Write an article". You want to get more people writing? Making the story creation process less scary. Wikinews:Writing an article is 6 (printed) pages long. tl;dr. --ShakataGaNai ^_^ 01:35, 5 September 2009 (UTC)[reply]

Proposal - depopulate/remove "reviewer" user group

I'd like to suggest we depopulate or even remove the user group Wikinews:Reviewer. Since FlaggedRevs has been installed well over a year ago, the group has never been used, as the "sighting" function provided by Editor status has always been sufficient for our needs. IMO this group is redundant, it just creates extra unneeded clutter at Special:Userrights and other pages policy pages and frequently confuses newbies. Thoughts? Tempodivalse [talk] 02:42, 8 September 2009 (UTC)[reply]

Current events

I propose Current events template on Main Page. Saqib Qayyum  talk  09:55, 9 September 2009 (UTC)[reply]

I'm not completely sure what the purpose of such a template would be. Isn't the entire Main Page already full of "current events" as it is, being a news site? Tempodivalse [talk] 17:31, 9 September 2009 (UTC)[reply]
I'm going to take a geuss: Are you proposing that a template be added that list ongoing events (ie events that have multiple articles associated with them, and our likely to have more coverage in the near future). Is that what your proposing? Bawolff 23:00, 9 September 2009 (UTC)[reply]
Yea, I'm kinda wonder where and for what purpose. Plus I think there are probably better ways to present that information. --ShakataGaNai ^_^ 23:04, 9 September 2009 (UTC)[reply]
I'm proposing a sidebar template that list Current events and Ongoing conflicts. Each link to a specific category. Saqib Qayyum  talk  08:48, 10 September 2009 (UTC)[reply]
I think the biggest drawback would be the need to manually maintain this. --Brian McNeil / talk 12:25, 11 September 2009 (UTC)[reply]
Take a look at this page, right side after Orignal reporting. Saqib Qayyum  talk  15:52, 13 September 2009 (UTC)[reply]
I tend to agree with Brianmc. If we were to do this though, i think linking to a category would be kind of ugly. it would be better to link to a portal page, or even a portal like page with information similiar to Portal:Australia/APEC_Australia_2007 (or just generally be more like Portal:Australia/In-depth_coverage as oposed to a category link). Bawolff 17:48, 13 September 2009 (UTC)[reply]
This is not a vote - there first needs to be a halfway decent idea and proposal. --Brian McNeil / talk 11:00, 14 September 2009 (UTC)[reply]

Newsroom

I would like to recommend a Protection policy that only registered users can create a new article. Saqib Qayyum  talk  09:48, 11 September 2009 (UTC)[reply]

Question I could think of some reasons to oppose such a change. What reasons do you have in mind to support it? --Pi zero (talk) 11:38, 11 September 2009 (UTC)[reply]
Comment I really have to agree with Pi zero here, why? Wikinews uses Flagged Revisions, so no unregistered user can actually {{publish}} an article. Such a restriction would severely limit the number of potential contributors. --Brian McNeil / talk 12:23, 11 September 2009 (UTC)[reply]
Comment I'm not sure this is a good idea. We have enough trouble getting people to write articles as it is, if we increased the bar to force users to register to create pages, this could potentially put some people off. And nobody who doesn't have Wikinews:Editor status can't get an article on the front page anyway. Tempodivalse [talk] 12:50, 11 September 2009 (UTC)[reply]

I'll go ahead and say what everyone else wants to say: REQUEST DENIED. --ShakataGaNai ^_^ 15:24, 14 September 2009 (UTC)[reply]

New currency templates

One of the regular things seen on Wikinews is quoting a value in one currency, then showing it converted to one or two other currencies. Here's a general idea of what would be useful for this:

  • {{currency value|25|GBP|USD|1.627|EUR|1.1052}}
Displayed as: £ 25 (US$ 40.7, 27.6)
The first parameter is the amount, the second is the ISO currency code which the amount is expressed in. Following this there are one or two pairs of values, the ISO code for a currency being converted to and the conversion rate for the date of the news.

I've assumed in the above example a default of one decimal places accuracy. The default may be more appropriate as two, but in any case a parameter such as 'precision=<integer>' could override any default.

The template will need inbuilt logic to convert currency ISO codes into an appropriate representation and wikilink. There may be a use for another optional parameter, say 'wikilinks=none', that suppresses use of wikilinks to the currency pages.

The only other thought I'd add to this is perhaps providing a unit or multiplier parameter, eg 'unit=million', and displaying this after each currency amount.

What do people think about this, and can we build some gadgets or other tools to help fill in the parameters (such as by reading current currency rate data off some external website)? --Brian McNeil / talk 12:48, 19 September 2009 (UTC)[reply]

That sounds like a good idea, I'd support implementing something like this. One note, since currency rates change over time, won't we have to subst: the template for it to correctly reflect the content of the article it's in? Tempodivalse [talk] 13:03, 19 September 2009 (UTC)[reply]
No, the template will not need put in place with subst, that's why I have the actual on-the-day exchange rates as parameters within the template. I do think {{currency value}} is a rather long template name, would {{money}} be better, and still meaningful to most contributors. --Brian McNeil / talk 13:05, 19 September 2009 (UTC)[reply]
As I build this I'm running into a few questionable points.
  • "franc" appears multiple times for different currencies and there is no alternative short code - Do we rely on the link, or put <foo> franc? Do we assume the plural and use "francs" instead of "franc"?
  • As with franc, there are several other currencies codes where there could be singular/plural questions. Remember, one case is "Euro", the plural of which is the same, i.e. "Euro".
  • Non-latin codes for currencies. A number of the currencys from Cyrillic or Arabic regions have non-latin text/codes. Should we use this?
Other issues? --Brian McNeil / talk 14:46, 19 September 2009 (UTC)[reply]
As far as other tools to fill in the template: that sounds great, but its not happening as a javascript gadget due to the Same origin policy (unless we have a bot update the js source with new currency values at regural intervals. could be tied into market data bot i suppose). For franc, i think we should put <country> frank. Plural/singular forms I don't think will come up very often, since how often do you see a singular dollar in a news article. If it does, this could be codded into the template using {{plural}}. I'm not sure about non-latin codes. Are articles are in english, so i think its reasonable to presume we'd use latin codes. Bawolff 23:41, 19 September 2009 (UTC)[reply]
Perhaps for unknown currencies we should just pass through the currency code given. Bawolff 01:38, 20 September 2009 (UTC)[reply]
  • I started working on some of the other parts:

{{money|USD|10.53242342|CAD|10000|AMD|12.45234|CNY|6435.324243|GBP|12904|EUR|12.5453}}→ US$10.53 (C$10 thousand, dram12, yuan6.4 thousand, £12.9 thousand, 12.55)

  • Basically it works by calling {{money}} which than calls user:Brian McNeil/money to convert the currency code to the link/fullname, and calls {{money/toDec}} to figure out precesion.
  • There's a problem with big numbers with all the trailing digits 0 going to exponential notation:
  • Also note, I've made it add commas every three decimal places for clarity. However thats kind of confusing with the commas seperating the different currencies

C$1,200,000 thousand (C$120,000,000 thousand, C$1,203,234,243,320,000,000,000,000 thousand)

  • I'm not sure if we want to include non-latin scripts that are RTL. For example is the below what we want? (i geuss we could overide the bidi if it isn't, but i think its easier just to stick with latin, as most of our readers won't understand the arabic anyway):

C$120 thousand (dirham13,501,230,324.23 thousand, Bolivian Mvdol14,503.25 thousand)

  • Precesion defaults to what is normally used by that currency. It can be changed with a flag:

{{money|USD|120.54321|precision=3...}} → US$120.543

{{money|USD|12012.54321|precision=-2...}} → US$0 thousand

Bawolff 01:38, 20 September 2009 (UTC)[reply]

  • The gadget idea isn't to maintain currency data here on Wikinews, but to provide an easy way to insert a {{money}} template with current exchange rate data. You launch the gadget, specify the amount and the currency it is expressed in, give the other one or two currencies you want equivalents shown for, then it generates the template code to insert by looking up the rate information somewhere else. This "somewhere else" bit is the issue, some of the rates for these obscure currencies aren't readily available.
  • There are some issues do need discussed about adopting this approach to monetary values. How would we update the style guide to cover this? What are appropriate currencies to express values in? I think a good argument could be put that, as an example, for a story about Jamaica you'd express amounts in their local currency and convert to USD and EUR to make the amounts meaningful to as wide an audience as possible. --Brian McNeil / talk 10:45, 21 September 2009 (UTC)[reply]
  • {{money}} really doesn't seem to be much use. In writing news the vast majority of monetary values given will be things like 1.2 million X.
  • I completed entry of the list of codes, excluded the various ones for precious metals and obscure trading units, and moved the whole lot to {{Money/ISO 4217}}. --Brian McNeil / talk 16:09, 21 September 2009 (UTC)[reply]
The issue with using a gadget with an external source - is due to security restrictions that is unlikey to work easily (js can only load data from the domain that it originated on). We can work arround that by using an external script (the only thing that javascript can load not from the same domain access is other script files to execute). Thus we could use something like http://currencyconverter.55uk.net , however thats trusting them to not send us any evil javascript. A better approach might be to get someone (Zach maybe) to make a simple perl script on the toolserver to query google calculator, and than return the result in the right form, but i don't know if there is legal issues with that. Bawolff 16:14, 21 September 2009 (UTC)[reply]

[unindent] Some examples with units:

{{money|USD|987|CAD|1412}} → US$987 (C$1.41 thousand)

{{money|USD|987|CAD|1412.3|units=million|precesion=1}} → US$987 million (C$1.4 billion)

Bawolff 20:56, 21 September 2009 (UTC)[reply]

Review time "limit"

I seriously think we need to cap the amount of tme between a request for review and a decision to publish or not. Delaying reviews are hurting the credibility of Wikinews IMHO. My suggestion is to have something like a six hour time before we "have to review" an article. I'm open to suggestions --05:39, 20 September 2009 (UTC) —The preceding unsigned comment was added by RockerballAustralia (talkcontribs)

I'm not sure how this would work. What if, after the time limit is up, there is nobody online to review? And if there are reviewers online, then we're going to force them to review the article? Everyone here is a volunteer, and does only what they want to do when they want to do it. imho, obliging users to review articles, even when they don't want to, isn't a good idea and could drive some people away. I know I wouldn't like it if I was obliged to review articles against my will (although i don't mind reviewing articles, there are times when i'd rather do something else on-wiki, like write an article etc.). I think the best solution to this problem is try to get a larger user base, and try to promote more Editors. Tempodivalse [talk] 12:42, 20 September 2009 (UTC)[reply]
I'm with Tempo here, but I can think of an alternative suggestion: Can we set up something in Category:Review similar to the list of changed sighted articles that tells us exactly how long an article has been sitting in review for, and order them oldest first? That would help draw attention to stuff that had been waiting awhile. Blood Red Sandman (Talk) (Contribs) 12:51, 20 September 2009 (UTC)[reply]
That sounds like a good idea. Can't DPL be set up to list articles in the chronological order in which they were last edited? Tempodivalse [talk] 13:46, 20 September 2009 (UTC)[reply]
The idea behind the "time limit" was so we could keep new editors from getting frustrated then not return. but arguments against are good and seem to address the prblem--RockerballAustralia (talk) 21:52, 20 September 2009 (UTC)[reply]
DPL could be set up to order by last edit or the time the review tag was added. However the problem is that it only provides the date, not the hour the tag was added. We could make it so that the reviewAlert gadget is always on regardless of your settings when you view CAT:REV. Bawolff 22:04, 20 September 2009 (UTC)[reply]
Force review my football, no pun intended. There is no way you're ever going to force it, EVER. Our review system isn't the most awesome, but thats the way it works. It just so happens that you get to see the dark side of it. Most of what you write is Australian Rules Football, is it not? With the except of you and DizzyStar, no one else wants anything to do with them. I review them when I can/have the energy, but lets be honest, I don't know jack shit about it. Most people that do reviews on a regular basis don't want to get involved with it because they don't know jack shit about it either. You could claim all sorts of obscene things about a game, and we'd never know any better - and that makes most reviewers very neverous. But lets take Wikinews previews the 2009 Brownlow Medal for example. All you did was copyedit it, why don't _you_ review it? Most reviewers do copyedit what they are reviewing. --ShakataGaNai ^_^ 16:22, 21 September 2009 (UTC)[reply]
just as a note, Rockerball had his editor status removed recently (see WN:FRRFP), so he can't currently do any reviews. Tempodivalse [talk] 16:38, 21 September 2009 (UTC)[reply]
Also I had added some OR to it so I didn't want to review it just I case I shouldn't have.--RockerballAustralia (talk) 20:42, 21 September 2009 (UTC)[reply]
I don't know how viable this would be, but I think it may be a good idea to have an article automatically reviewed by the software/a bot after a certain time limit, as long as it had not already failed a review, and add a template to the top of the article that says "This article may contain some innacuracies, as it has not yet been reviewed by a human editor." These articles could then be placed into a separate category, but would otherwise act just like normal published articles. Then a human could come along and manually review/un-review the article. Dendodge T\C(en.wp) 17:11, 21 September 2009 (UTC)[reply]
That's probably not a good idea. A bot could easily let through articles that are copyvios or blatantly violate our policies, like NPOV or newsworthiness, and possibly could damage our reputation or get us kicked off Google News. I think it's best to have a person do it, even if it means a slightly longer wait time for an article to be published. Tempodivalse [talk] 17:26, 21 September 2009 (UTC)[reply]
The full name of the process is peer review. The point is to certify that a qualified sapient mind has examined the article and judged it to meet the criteria for publication. If we don't consider all sapient minds qualified, then surely we wouldn't afford that privilege to a bot that can't pass the Turing test.
While we're brainstorming, though — Reviewing is a multi-faceted operation, with a specific number of facets (copyright, newsworthiness, verifiability, NPOV, style). So, what would happen if we (somehow) split up the review process into these individual facets, so that different editors could certify that an article meets the different criteria?
  • Would reviewing a subset of the criteria be enough easier than reviewing them all that it would make any observable difference in how fast articles get reviewed?
  • How could one readily be sure, if different criteria are being reviewed at different times prior to publication, that all of them are actually being reviewed by editors?
--Pi zero (talk) 21:45, 21 September 2009 (UTC)[reply]
First question: No, unless there was a highlevel of communicastion between the reviewers and they did their reveiwing simultaniously. Second: see previous answer.--RockerballAustralia (talk) 05:02, 22 September 2009 (UTC)[reply]

(Unindent) Why don't we go with a bot thing, but not use the curid in the URL? That keeps things off Gogle News until human-checked, but does get them out. I'm not at all sure I like the idea, and considering it's mine that doesn't bode well for it, but I just thought I'd throw that out there anyway. Blood Red Sandman (Talk) (Contribs) 06:20, 22 September 2009 (UTC)[reply]

I'm against any sort of bot reviewing or publishing articles, even if they don't get out on Google news (remember we're still mirrored on several other sites and have news feeds at twitter etc.). As i said above, a bot has no way of determining an article's copyright, neutrality, and other style issues that need to be met for publishing. imho we ought to strive to be as accurate and professional as possible (we've had enough problems with that in the past), and having a bot autopublish things without human oversight isn't going to help things much. I think that the best solution to this is to try to nominate more users for Editor status, so that they can help clear backlogs. We could also have a "first-come, first-served" basis for article reviewing (i.e., an article that was put up for review first should be reviewed first, we could use DPLs to do that), to prevent articles from staying in the queue until they're stale. Tempodivalse [talk] 13:43, 22 September 2009 (UTC)[reply]
Bots doing reviews? Bad idea. Cirt (talk) 16:14, 22 September 2009 (UTC)[reply]
Also from a technical prespective, that would be difficult to implement having some articles have curid, while others don't (unless we have two seperate lists). Google news also would pick up on some articles that don't have curid if they have a # in title. But most importantly, as Cirt said, bots should not do reviews. Bawolff 16:22, 22 September 2009 (UTC)[reply]

[unindent] I was bold and made some changes to CAT:REV to try to address some of the issues raised (that people don't know how long something has been waiting). You may have to do a hard refresh. If you don't like them feel free to revert. People who use readyAlert gadget won't notice the difference. Bawolff 16:37, 22 September 2009 (UTC)[reply]