Wikinews:Water cooler
|
Welcome to the Water Cooler
|
|
|
|
Policy |
Technical |
|
Proposals |
Assistance |
Miscellaneous |
Other discussions elsewhere
You are also invited to be involved in the following flagged conversations happening elsewhere on the Wiki. Add {{flag}} to a page to have it listed here.
Open polls
Please vote in open polls! Add {{poll}} to a page to have it listed here.
| I want to... | Where to go | |||||
|---|---|---|---|---|---|---|
| Get help using Wikinews | Help contents | |||||
| Get collaborative help on an article | Newsroom | |||||
| Comment on a specific article | Article's talk page | |||||
| Use a reference desk (e.g., "Can someone check this fact?") | Reference desk | |||||
| Make wiki software bug reports and feature requests | MediaZilla | |||||
| View other Wikimedia projects | Wikimedia Meta-wiki | |||||
| Help to promote Wikinews | Spread Wikinews | |||||
| Report Mirrors and forks | Mirrors and forks | |||||
Wikinews news
- Both Brian and Skenmy were elected to the Arbitration Committee after C628 resigned.
- On August 2, voting opened in the ArbCom runoff election. The candidates are Skenmy and Brian.
- Voting in the ArbCom election closed on July 30. Five arbitrators were elected. Votes for the sixth seat tied.
- Edits are no longer auto-sighted. Don't forget to sight your own minor edits. There is a new gadget to help with this.
- Things needing doing:
Accreditation requests: 0 Requests for permissions: 1 Flagged revs requests: 0 Bot requests: 2 FA candidates: 3 Deletion: 3 Articles needing review: 9 Quiz: Fix me! Edit
Policy
|
|
Policies and guidelines and the Style guide contain or link to most of the current en.Wikinews policies and guidelines, however policy is based on the accepted practices of the day on Wikinews, often these might not be written down. This section of the Water cooler focuses on discussions regarding policy issues.
You may wish to check the archives to see if a subject has been raised previously.
Strategic Planning
The Wikimedia Foundation has begun a year long phase of strategic planning. During this time of planning, members of the community have the opportunity to propose ideas, ask questions, and help to chart the future of the Foundation. In order to create as centralized an area as possible for these discussions, the Strategy Wiki has been launched. This wiki will provide an overview of the strategic planning process and ways to get involved, including just a few questions that everyone can answer. All ideas are welcome, and everyone is invited to participate.
Please take a few moments to check out the strategy wiki. It is being translated into as many languages as possible now; feel free to leave your messages in your native language and we will have them translated (but, in case of any doubt, let us know what language it is, if not english!).
All proposals for the Wikimedia Foundation may be left in any language as well.
Please, take the time to join in this exciting process. The importance of your participation can not be overstated.
(please cross-post widely and forgive those who do)
Location categories
If an article belongs to a location subcategory, does that automatically mean it should be in all location categories that are ancestors of that subcategory? Also, under what circumstances might the article be about a particular country, but also be in a higher-level regional category that doesn't include that country? To make those questions more concrete:
- Hiroshima marks 65th atomic bombing anniversary belongs to Category:Japan, Category:United Kingdom, Category:United States, and Category:France. I figured that since it actually took place in Japan, it surely ought to belong to Japan's parent, Category:Asia. But should it also belong to the other categories' parents, Category:North America and Category:Europe — and if so, what about Category:European Union (which I'm not sure whether or not to think of as a location category)?
- An even more extreme example of that is that 21 sites added to Unesco World Heritage list belongs to... well, a lot of specific location categories, and then also Category:South America (presumably because the conference took place in Brazil) and Category:North America (I'm not 100% sure why) — but based on the specific locations, it would also belong to Category:Asia, Category:Europe, and Category:Oceania.
- Revenge killings follow shooting of Karachi politician belongs to category Karachi, and its ancestors Pakistan and Asia. But it also belongs to Middle East; should it, and why or why not?
- Looking at the articles in Category:Afghanistan, I see that, crudely speaking, 40% of them do not belong to Category:Asia, and 25% of them do belong to category Category:Middle East. Those two aren't even significantly correlated: 30% belong to neither, and 15% belong to both.
--Pi zero (talk) 05:32, 14 August 2010 (UTC)
- yes, we use categories in wikinews atomically (is that the right word?). Something in category:Alberta should also be in category:Canada and category:North America, otherwise the portals break (because doing category intersection of category + anything in its subcategories is quite expensive so dpl doesn't support that sort of thing.) Bawolff ☺☻ 05:41, 14 August 2010 (UTC)
- In most cases, I'm with Bawolff - but, in cases like the Unesco thing, one might argue that it wasn't so related to the continents that it should be turning up in them (the irony of that example being, if it was a single site then there would be enough focus for the location's parent continent to join in). As to whether we should make those kind of judgement calls is another matter entirely.
- To address the issue of the EU cat - no, that's not a geocat to me. Blood Red Sandman (Talk) (Contribs) 11:24, 14 August 2010 (UTC)
My thinking now on the first point: Category:Oceania, say, can be interpreted at one extreme as identifying articles that relate to the whole of Oceania, in which case I wonder if the category might get deleted for having too few articles in it; or at the other extreme as identifying articles that relate to some part of Oceania. Bawolff's point about intersection categories seems to me to make it impossible to compromise between these two extremes, since it demands that there be no exceptions. Framed in those terms, I think
<DynamicPageList> category=Oceania category=United Nations </DynamicPageList>
should include the Unesco article, so I find myself persuaded to Bawolff's position.
This has implications for Category:European Union. The category-intersection argument should apply to all categories that might be used in an intersection search for articles; so as long as Category:France is a subcategory of Category:European Union, every article that belongs to Category:France should belong to Category:European Union. That makes EU a location by any other name. If there are some articles about France that are not about EU, then Category:France should not belong to Category:European Union. --Pi zero (talk) 19:57, 15 August 2010 (UTC)
- Oceania is not an organisation. The EU is, just like Adam Air or the United Nations. Note that if you extended that to the UN, then every country in the world would be in the cat. (Well, there's around four nations not represented...). Blood Red Sandman (Talk) (Contribs) 20:00, 15 August 2010 (UTC)
-
- Countries belonging to the UN are not subcategories of Category:United Nations. Countries belong to the EU are, however, subcategories of Category:European Union; in fact, they seem to be the only subcategories of Category:European Union. --Pi zero (talk) 21:31, 15 August 2010 (UTC)
-
-
- That rather begs the question of why those subcats are there in the first place... Blood Red Sandman (Talk) (Contribs)
-
-
-
-
- Agreed. If whether it is a location category depends on whether it has the subcats, then the addition of the subcats amounts to turning it into a location category. Category:France was made a subcategory of Category:European Union on 21 March 2007. That's almost two years after Category:European Union was created (13 May 2005).
-
-
-
-
-
-
- All of which has (belatedly) led me to this and this. Apparently the question was not whether Category:European Union is geographical, but whether Category:France is geographical. It seems to me that the, er, geographicality of France is long settled by precedent. --Pi zero (talk) 22:26, 15 August 2010 (UTC)
-
-
-
- To comment, adding all the members of the UN to that cat seems fine. That's 192 countries, all except the Vatican and Kosovo (plus Taiwan, if you count it), maybe excessive, but it makes sense. —Mikemoral♪♫ 20:57, 16 August 2010 (UTC)
-
- My position is that if categories X and Y may both be used for constructing DPLs of articles, and X is a subcategory of Y, then every article that belongs to X should belong to Y. If it isn't true that every article in X should be in Y, then X shouldn't be a subcategory of Y.
-
- Therefore, if the 192 countries were added to Category:United Nations, it would be necessary to add most of the articles on Wikinews to Category:United Nations, making it a largely useless category that should probably be deleted. Since I take the position I do on the relationship between categories and DPLs, and I don't want Category:United Nations to become useless, I oppose adding the member countries to it.
-
- For the same reason, I think the current subcats should be removed from Category:European Union.
- Both Category:United Nations and Category:European Union are about political entities. Such categories should only apply where they unambiguously relate to news about the political entity. --Brian McNeil / talk 23:32, 16 August 2010 (UTC)
-
- Exactly. --Pi zero (talk) 02:44, 17 August 2010 (UTC)
- So,... Pull every single country out of
the UNthese categories. Or, only apply a country-level geographic category where it is relevant, such as UK implements another, hated, pro-freedom Euro-law. ;-) --Brian McNeil / talk 03:12, 17 August 2010 (UTC)
- So,... Pull every single country out of
- Exactly. --Pi zero (talk) 02:44, 17 August 2010 (UTC)
Whole versus sum of parts
Perhaps each country category should be split into two (if there are enough articles to warrant it): a geocat, with the current name, and an orgcat (because "polcat" is too much like "polecat") whose name has a parenthesized modifier on it. Choosing a lucid, non-POV modifier may be tricky; for now, I'll just use " (org)".
My reasoning:
- At the city level, it seems sufficient to use a single category for both purposes.
- At the continent level, there's no political entity, so continents are pure geocat with no associated orgcat.
- Other entities above the country level, besides continents, are uniformly political; so they should be pure orgcat with no associated geocat.
- At the country level, though, one may want to construct queries using either the geocat or the orgcat, and the scale is large enough that membership of the geocat may swamp that of the orgcat.
- Assigning the unmodified name to the geocat, rather than to the orgcat, will be easier to use and will cause fewer and less severe errors.
Details:
- Each country orgcat would belong to the corresponding geocat. Geocats never belong to orgcats.
- Geocats belong to other geocats based on geographical containment. Orgcats do not belong to other orgcats based on being member states.
Example:
- There would be Category:Paris, Category:France, Category:France (org), Category:European Union, and Category:Europe. Category:Paris is both geo and org. Category:European Union is org. Category:Europe is geo. Category:Paris is in Category:France, and Category:France in Category:Europe. Category:France (org) is in Category:France, and Category:European Union is in Category:Europe.
Paris
|
v
France <- France (org)
|
v
Europe <- European Union
--Pi zero (talk) 18:01, 22 August 2010 (UTC)
- (Putting on SA hat) What is the problem you are trying to solve?
- If you're looking for the equivalent of a Category:Politics of France, that's what DPL is for.
- Every article should be in at least one topical cat and one geo cat. If I'd some clue where the perceived problem was, I might be able to suggest something. --Brian McNeil / talk 19:54, 22 August 2010 (UTC)
Is it bias to leave my signture on an article?
When I write articles I make sure to leave my name on the article.... Yet some editors think that is bias or as if I'm taking a non-neutral point of view on the subject... I don't see that and I haven't run into anything in the Wikinews policy that says I can't leave my signature on an article. What does the group think?--Yamariel (talk) 22:49, 15 August 2010 (UTC)
- It's simple, you can't. Diego Grez return fire 22:50, 15 August 2010 (UTC)
- There are a variety of hidden templates for regular contributors to flag articles where they are the main authors. Concern has been raised because what you submitted appears quite similar to what is written elsewhere. That is more of an issue to address. --Brian McNeil / talk 22:52, 15 August 2010 (UTC)
Correction notice for factual clarifications?
The discussion Talk:NCAA 2010 ice hockey east and west regional tournament results#editprotected remains unresolved after three weeks. Please have your say. --InfantGorilla (talk) 10:35, 23 August 2010 (UTC)
Technical
|
|
Facebook to Russian Wikinews
We've got Russian Wikinews. Is there a way we can attach Facebook plugin to news stories, so people can "like" and comment them on Facebook? --Ssr (talk) 18:24, 24 July 2010 (UTC)
- I think something might be wrong with the Facebook updates... Benny the mascot (talk) 19:14, 24 July 2010 (UTC)
- Does {{Social bookmarks}} do what you want? An actual like button might be harder. Bawolff ☺☻ 21:31, 24 July 2010 (UTC)
- We'we got an analog of {{Social bookmarks}} at ru:Шаблон:Социальные закладки (can someone please add interwiki to the protected page at {{Social bookmarks}}?) but in can only share, and I wonder about built-in "Like" button: there's a Facebook plugin for websites that can be integrated like this: http://bugtraq.ru/rsn/archive/2010/07/10.html. This could be a great advantage for Wikinews. --Ssr (talk) 03:12, 25 July 2010 (UTC)
- There might be privacy implications. The privacy implications are limited by the fact that this uses an iframe (due to same origin policy), which is much better than the usual way these things are done by loading remote js code. However facebook would still be able to get statistics about how many people visit each wikinews page with the like button on it, what browser they use, if they are logged into facebook, who they are on facebook, if they are the same person who visited the page 2 hours ago, etc. Since there are strong privacy implications, someone at the foundation would have to tell us that its ok with privacy policy and all before we'd do it. Bawolff ☺☻ 07:15, 12 August 2010 (UTC)
- We'we got an analog of {{Social bookmarks}} at ru:Шаблон:Социальные закладки (can someone please add interwiki to the protected page at {{Social bookmarks}}?) but in can only share, and I wonder about built-in "Like" button: there's a Facebook plugin for websites that can be integrated like this: http://bugtraq.ru/rsn/archive/2010/07/10.html. This could be a great advantage for Wikinews. --Ssr (talk) 03:12, 25 July 2010 (UTC)
- Does {{Social bookmarks}} do what you want? An actual like button might be harder. Bawolff ☺☻ 21:31, 24 July 2010 (UTC)
From a privacy policy point of view, anything which allows third parties to track user patterns would be out -- passive buttons stored locally and linking to remote services are OK.--Eloquence (talk) 16:56, 16 August 2010 (UTC)
Proposals
|
|
Article format redesign
So forgive me if this is a perennial proposal (I did search the archives briefly, but didn't see anything similar), but our current article format is outdated and simply doesn't keep up with other major news outlets. I did a quick mockup of what I think is a more "current" design at User:Fetchcomms/test. I'm just looking for feedback, but I hope that we can do a revamp of the articles sometime in the near-ish future. Perhaps even just one or two changes I made will seem feasible project-wide. —fetch·comms 03:15, 1 August 2010 (UTC)
- Seems good, but it would be a pain to change all of our articles to that format. Diego Grez return fire 03:16, 1 August 2010 (UTC)
- I'm not so sure about the byline, though. We're a wiki, and we don't own our articles. Other than that, I think the new design looks great! (Diego, I think the new design won't be implemented on previous articles.) Benny the mascot (talk) 03:24, 1 August 2010 (UTC)
- (edit conflict) I think pictures should stay on the left. There's an edit section, which should be removed. I wonder if we can suppress the "(UTC)." It adds an extra line. I'm also not a fan of the byline I think a Wikinews redesign is a great idea. It looks good with a real article. —Mikemoral♪♫ 03:37, 1 August 2010 (UTC)
- I like it, especially the use of subtitles. My one major issue would be the justified text, which while it can look nice, is not yet advisable for use on the web. The byline question is something we'll need to have a separate discussion about (personally I'm in favour, but I can see why people might have issues with it). the wub "?!" 10:02, 1 August 2010 (UTC)
- I generally like the look. I would reserve the byline for WN:OR only. --Александр Дмитрий (Alexandr Dmitri) (talk) 12:18, 1 August 2010 (UTC)
- I like it, especially the use of subtitles. My one major issue would be the justified text, which while it can look nice, is not yet advisable for use on the web. The byline question is something we'll need to have a separate discussion about (personally I'm in favour, but I can see why people might have issues with it). the wub "?!" 10:02, 1 August 2010 (UTC)
- (edit conflict) I think pictures should stay on the left. There's an edit section, which should be removed. I wonder if we can suppress the "(UTC)." It adds an extra line. I'm also not a fan of the byline I think a Wikinews redesign is a great idea. It looks good with a real article. —Mikemoral♪♫ 03:37, 1 August 2010 (UTC)
- I'm not so sure about the byline, though. We're a wiki, and we don't own our articles. Other than that, I think the new design looks great! (Diego, I think the new design won't be implemented on previous articles.) Benny the mascot (talk) 03:24, 1 August 2010 (UTC)
- I certainly hope we wouldn't be planning to change format for older articles (we don't seem to have with minor changes in past, either). The editsection can easily be removed (although I will need to fix the subtitle code for smaller screens and long subtitles). The extra line in the date is caused by a smaller screen as well (widths are relative %), so if we remove the UTC we might as well dump the hour/minute as well or just make that text even smaller. Removing the justification is fine as well, as is removing the byline or just leaving it for certain occasions like interviews, etc., where we often already mention the author's name in the article.
- Any further feedback is welcome! Also, as it seems to have been well-received here, does anyone have ideas on where to go next--should we open some "official poll", or something else, etc.? Thanks, —fetch·comms 19:38, 1 August 2010 (UTC)
-
- No. --ShakataGaNai ^_^ 19:55, 1 August 2010 (UTC)
The only major changes I see are is a subline, and a different styled infobox - which has nothing to do with the article layout itself. We could make the infoboxes like that now if we wanted to. As for the Byline, that needs to go - 100%. We're WIKInews, not "I wrote this article"-news. We all wrote the articles. Also, no need for the published time. We do update our articles after publication (Sometimes a lot). If people see a published time, they'll presume nothing has changed since that time. --ShakataGaNai ^_^ 19:55, 1 August 2010 (UTC)
- I condensed basically every non-article component into a sidebar, so I guess it's not really an article redesign, but a page redesign. So you are opposed to even a "Interviewed by User:X" on such pages? As I said before, we often mention that in interview articles. I will change the published time to just the date, as presented now. Thanks for the comments! —fetch·comms 20:02, 1 August 2010 (UTC)
- Do you think you can get the sharing links thing on one line? —Mikemoral♪♫ 23:41, 1 August 2010 (UTC)
- Try it now. If it's still too narrow, I'll make it a set width. —fetch·comms 00:24, 2 August 2010 (UTC)
- I think it looks great now. I hope we can implement a new format soon. —Mikemoral♪♫ 05:55, 2 August 2010 (UTC)
- I wanted to comment here earlier in the discussion but I couldn't. Redesigning the page sounds like a good idea at the moment. As Fetchcomms said originally, it is a bit outdated compared to the sites of some news providers. Anyway, not to discredit Fetchcomm's design, but why aren't a few people designing new page ideas so that the community can !vote and form a consensus?
- Some notes about Fetchcomm's design. I preferred it when the first image was on the right side next to the infobox template. It has always seemed strange to have the text sandwiched between the image and the template. I don't know of many places that do this, but when they do it's not as obvious as we make it. A second image when the article has one could be placed on the left, lower down the page, and this is more pleasing on the eye than having two images stacked on the left or having one tucked away underneath the infobox, which is what can happen. As for the byline, yes we're a wiki, and yes everyone contributes, but the original story is almost always by one person. People put articles into their own personal categories and list them on their userpages anyway. Performing cleanup and copyediting, and reviewing, doesn't take away from the fact that the story is from one person, and I'd like to be able to click on the original author's name and see what else they've written. The sub-headline is a nice touch, but is that going to be an optional thing or will every article have to have one? Removing the images from the infobox is a good idea, as they often have little to do with what the article is about, but I think we should keep the collaboration part -- we do want people to write here, right? Finally, in that share this story template, if it's possible, isn't it about time we added an "Email this" button, and the Facebook "Like" button as well? Matthewedwards (talk) 14:52, 2 August 2010 (UTC)
- I prefer Matthew's image idea as well--we can switch images later, if needed, or just let the writer decide where to put the image(s). The byline debate should probably go into a proposal of its own, as it will be hotly debated, I expect. It's also easy to add/remove from my design, so not a very big deal in regards to the design. I think that subtitles can be optional, although I expect that many, if not most articles, will have them. Collaboration--I'll add an extra section for that. And I'm not sure how to do that with wikicode--I expect it'll need to be done with some javascript for the email and facebook like button. —fetch·comms 17:55, 2 August 2010 (UTC)
- I think it looks great now. I hope we can implement a new format soon. —Mikemoral♪♫ 05:55, 2 August 2010 (UTC)
- I like it. I hope there is a technical way to make the proposed new infoboxes work without mucking up the layout of archived articles or forcing contrived template names on authors.
- Please make separate proposals for the ideas of a sub-title and a byline, so you can explain the purpose of those items and persuade the community on their merits and de-merits. (By the way, I want to promote more and bolder collaboration on articles, so I think bylines should be optional and discouraged. Some of Wikinews 's most important output has been deeply collaborative, while much has indeed been outstanding individual effort and talent. Of course interviewers, photographers and on the scene stringers should be proud to name themselves, by pen name not username, in the body of the article.)
- Can you make room for something like {{dateline}}?
- Please never forget narrow screens. When we have finalised a draft layout, I guess you need to plan a thorough review to double check that the key information is always available to feed readers, screen readers, mobile phones and iPods of various types, set-top boxes, game consoles, non-Javascript browsers, dial-up and image-disabled browsers.
- I agree with Matthew's comment about the text sandwich made by the first image. I think the image shouldn't go on the left unless it is particularly newsworthy in itself, such as free on-the-scene documentary photography.
- --InfantGorilla (talk) 16:24, 2 August 2010 (UTC)
- I'm thinking of making just a new, single template page, so it won't affect old pages and there'll be no more juggling of templates. I'm leaving out bylines for now, and subtitles can be configured to be optional, a it seems well-received by most. In User:Fetchcomms/test, I'm using {{dateline}} now; I had the date in the sidebar but it was suggested to move it back to above the article by someone else earlier. I have access to narrow screens, so I can easily test that. Although I don't really think any site looks good on iPod Touches :P For non-js browsers, I thought that the "Opinions" tab was js-generated, and I'm not adding anything new as of yet (but I would like a Facebook like button and email to others link). I will change the image now, as it seems to be 2-1 in voiced opposition. Any other suggestions on pic placement are welcome. —fetch·comms 18:01, 2 August 2010 (UTC)
OK, so I figured out email links. The Facebook Like bit can't be done with just wikicode/html here, though (requires either javascript or use of an iframe element). —fetch·comms 00:33, 4 August 2010 (UTC)
- Try this: I think I got the email link working, pretty sure this can be added to the current social bookmarks template now. —fetch·comms 00:57, 4 August 2010 (UTC)
- Yep, just confirmed with two others that underscores is all we're gonna get. Check the link for an example of what I mean. The_article's_poor_title_:( —fetch·comms 03:21, 4 August 2010 (UTC)
Comment Can you please address the comments/points I raised on the talk page of your test redesign? Or, otherwise incorporate them into this discussion? -- Brian McNeil (alt. account) /alt-talk • main talk 05:20, 4 August 2010 (UTC)
(copied over here to keep the discussion in one place)
I've not seen all the discussion on this, but, from what I have, the following points are those I'd raise...
- Related news is for directly related Wikinews stories, not a generic list from one of the top-level stories; as current infoboxes are. That is, related news is where we source from our own earlier content.
- This look great on a big monitor. Thus it excludes netbooks, mobiles, users of older machines.
- Dates. UTC? Absolutely! It clarifies thing where sources use their timezone-specific date; thing Sydney Morning Herald.
- Date granularity. No finer than a 15 minute point to match with push via twitter &c. A 'last updated' might be nice, but can it avoid weirdness with the archiving a few days later?
- How simple will this be for a new contributor who is non-technical to create a publish-ready article?
- How will this cope with the frequent really short articles that just meet minimum publishable guidelines.
- Sub-headings. Unless you're talking a 2-3k-word article, they're redundant.
- Bylines? Unwiki. What we have just now are hidden cats for people to keep track of their work. That should suffice, and was mostly done for OR and competition usage.
Under no circumstances do I think this should be retroactively applied; but, might be worth trying on a random selection of articles to see the end result.
I'd looked at 'purloining enWP's article cteation tool. That might be a better pririty to tackle. -- Brian McNeil (alt. account) /alt-talk • main talk 18:44, 2 August 2010 (UTC)
- Should we use "Related stories" instead? That's what the current infoboxes say.
- It looks fine on both my iPad and iPod Touch.
- You mean like "August 4, 2010 (UTC)", or have the hour/minute in there too? There was some opposition to that above.
- Last updated will be likely impossible to do automatically, because revisiontimestamp will catch the archive (and edits that aren't really updates, like interwikis or vandalism reverts).
- This design can be wrapped up in one template. There will be parameters for the subtitle, infobox category, and text/pics/sources/categories. Should be about as easy as it is now, except the infobox doesn't need to be added by itself.
- For short articles, the sidebar should not reach down further than where the social bookmarks currently are (I just tested a short article in the redesign).
- Subheadings can be optional (if the param is blank, then it doesn't appear), and I think they would be useful for the occasional longer articles.
If you can find a "good" assortment of articles varying in length, a photoessay, interview, whatnot, that should give a good representation of what works and does not. We shouldn't bother with old articles, I agree. —fetch·comms 21:07, 4 August 2010 (UTC)
I mocked up a proposal similar to this one a while back, but yours looks much better than mine. I love it, and hope we can implement it soon. Δενδοδγε τ\c 11:42, 6 August 2010 (UTC)
- I've tried to make a template version of the proposal at User:Dendodge/Sandbox. I think it's relatively simple for new users to work out—it asks for six parameters (type, user, related, date, text, and sources), only three of which (date, text, and sources) are needed. "Type" defines whether it is original research (if so, it adds the byline—if you don't like that, the parameter can go). "User" is the name of the person who made the article, and is required for the byline (see previous comment). "Related" is for the infobox thingy. "Date" is the date of the article (this one can go if you'd rather just use {{date}}. I tried to get the current system of entering it automatically to work but I couldn't—maybe somebody could take a look?). "Text" is, quite obviously, the text of the article. "Sources" is where the sources go (this can be merged with "text" if you like). Therefore, we could get it down to two parameters ("related" and "text") if you think less is more, only one of which ("text") would be required. An example transclusion is viewable here. Δενδοδγε τ\c 18:07, 6 August 2010 (UTC)
- I forgot to mention "subtitle, which is an optional parameter and adds a subtitle. Δενδοδγε τ\c 19:38, 6 August 2010 (UTC)
- Transclusion looks great to me. For the date, I'd just use {{date}} with the {{date|{{<includeonly>subst:</includeonly>#time:F j, Y}}}} code rather than a parameter. Still not sure what the consensus for a byline is, but I'd remove that for now, or comment that part out, or whatnot when making a final version. Sources is probably easier merged with the text part, which would also include the images, etc. Otherwise, it seems to work well. —fetch·comms 18:54, 7 August 2010 (UTC)
- I tried that for the time, but it didn't seem to work when transcluded for some reason so I added the parameter as a compromise. I thought the sources might be easier for n00bs as a parameter, but it might be better in the text. Whatever. Δενδοδγε τ\c 17:49, 8 August 2010 (UTC)
- One other possible way might be to split it up into multiple templates. Instead of the article text as parameter one, do
{{article header|parameters...}} Article text here {{article footer}}. {{date|{{<includeonly>subst:</includeonly>#time:F j, Y}}}} won't work in a template, unless that template is substituted, as {{subst:#time:F j, Y}} is substituted at save time. if the subst is is includeonly, then thesubstonly appears during transclussion, and never when saving a page. You can use {{date|{{<includeonly>safesubst:</includeonly>#time:F j, Y}}}} which will subst if the containing template is substituted, and act like {{#time:F j, Y}} when transcluded, but I don't think that is that useful here. Bawolff ☺☻ 19:10, 8 August 2010 (UTC)
- One other possible way might be to split it up into multiple templates. Instead of the article text as parameter one, do
- I tried that for the time, but it didn't seem to work when transcluded for some reason so I added the parameter as a compromise. I thought the sources might be easier for n00bs as a parameter, but it might be better in the text. Whatever. Δενδοδγε τ\c 17:49, 8 August 2010 (UTC)
- Transclusion looks great to me. For the date, I'd just use {{date}} with the {{date|{{<includeonly>subst:</includeonly>#time:F j, Y}}}} code rather than a parameter. Still not sure what the consensus for a byline is, but I'd remove that for now, or comment that part out, or whatnot when making a final version. Sources is probably easier merged with the text part, which would also include the images, etc. Otherwise, it seems to work well. —fetch·comms 18:54, 7 August 2010 (UTC)
- I forgot to mention "subtitle, which is an optional parameter and adds a subtitle. Δενδοδγε τ\c 19:38, 6 August 2010 (UTC)
- I think that keeping it at a single template is best, because it's a lot easier for new users to use, and simpler in general. Maybe just put the date with the rest of the article text (not a separate param)? —fetch·comms 03:48, 9 August 2010 (UTC)
Feedback
I think this is a good way to push things, but not something to rush. I might add, voting is evil; it should not turn into a beauty contest to see who can create the purdiest layout. There's a whole bowl of spaghetti around what I'd stress is a workflow. Multiple components are involved; we need a fair bit of software development, as well as a more professional article appearance. My own work to create templates for relatively easily maintained, and consistent, portals is another component of the 'bigger picture'.
The MSM spend millions on hideous packages like SharePoint, then the same again to beat them into doing what they want. We do not have that sort of money; and, I am not a project manager. My IT background is systems analysis, mostly troubleshooting; but, with a lot of design and future-proofing work.
Can we work on resetting expectations of those with no software development experience? Contributing needs made easier; collaborating needs made easier; and, perhaps most importantly, reviewing needs made easier. These are all, currently, fragmented parts of a greater whole.
This is bold; but, is is bold enough? -- Brian McNeil (alt. account) /alt-talk • main talk 23:34, 4 August 2010 (UTC)
- I'm not sure I understand completely what you mean—that we need a design that is easier to use for writers, or that we need to add more functions (if so, which?), or that we should making more designs and (not?) voting on them sometime, or all or some or none of the above? —fetch·comms 02:22, 5 August 2010 (UTC)
- That this, the need for better reviewing tools, revamped portals, and various other issues that keep coming up all need rolled into one. -- Brian McNeil (alt. account) /alt-talk • main talk 05:01, 5 August 2010 (UTC)
-
- How do you propose we do that? Make some sort of web app on the toolserver? I agree that all those things you mentioned could be improved, but I'm not sure on their direct relationship to making a new page design. To try and bundle up many updates into one proposal would take a very long time, as some of these things need their own discussions. —fetch·comms 17:01, 5 August 2010 (UTC)
- Not a web app; the toolserver is, frequently, unreliable. I mean significant changes to FlaggedRevs to support a reviewing process. But, as I keep saying, it is a workflow we need to spec out. From that, it should be possible to pick out points like an article redesign and do those as and when people can. I doubt we'd complete all the changes I think are needed in anything approaching what most contributors would consider reasonable timescales. However, A map of where the project is hopefully going would give a clearer framework. I've a little time off this weekend, I'll try and expand on this and lay out my ideas then. there are so few Wikinewsies that duplicated, or wasted, effort should be avoided. -- Brian McNeil (alt. account) /alt-talk • main talk 05:36, 6 August 2010 (UTC)
- I agree that there are a number of ways we could make the site easier to use, and this could come as a part of that bundle. The Main Page is fine already, and has been changed far too often already, but articles, portals, and other reader-oriented pages could be improved. We already have a new-style portal template that Brian developed—we need to roll that (or something similar) out across the board. Things like MakeLead should be expanded to include category portals to ensure that portal leads are always up-to-date. We should also refine this proposal, make it as user-friendly as possible for both readers and writers, and start using it on all new articles. Reviewing could be better, but not too difficult to learn—while it can be improved, it shouldn't be the most important issue. We could do with some kind of site-wide redesign to make everything purdy and easy to use, followed by rabid article-writing (especially OR) to increase our user-base. We certainly need it after recent events. Δενδοδγε τ\c 18:26, 9 August 2010 (UTC)
Template
I thought the technical issues behind my template should probably be discussed separately to the design issues, hence a new section.
- I have created a draft template version of this proposal that can be applied to articles at User:Dendodge/Sandbox
- Examples of the template in use can be seen on User talk:Dendodge/Sandbox
- There is a longer example using a featured article with multiple sections at User:Dendodge/Sandbox/2
- Notice that I have put the sources and related news in the sidebar for this one—I think it looks a bit nicer on long articles, but it's not too important
- The parameters used in the template can be seen at User talk:Dendodge/Sandbox
Any comments? Δενδοδγε τ\c 19:55, 9 August 2010 (UTC)
-
- I like the look of the sources in the sidebar for longer articles. Everything else looks nice, and we could even put the FA box in the sidebar, too. For the regular template, I prefer the sidebar without the extra line at the bottom, if no extra text is needed. Maybe just bundle that with the parameter? Or does everyone else like it there. It's not a big deal to me, just looks cleaner without it. —fetch·comms 19:26, 10 August 2010 (UTC)
Requests for permissions re-formulation
Hi. I have been sorting old archives of requests for permissions in the past days and created a new layout for them, located at Template:RfA. I want feedback on the following points:
- Is the system easier to use? If not, how do you think it could be made easier to use?
- Should the "Notable works" be optional or necessary to do?
My thinking is that I did the first step for this re-formulation and sorting of the Requests for Permissions system. You do the rest :-) (well, I still have to finish the archives' sorting) Cheers and thanks. Diego Grez return fire 18:31, 9 August 2010 (UTC)
I've commented on the talkpage, but I'll repeat myself here. The entire history has been lost for all of the archived discussions.--Alexandr Dmitri (talk) 23:04, 10 August 2010 (UTC)- Appears previous archiving borked this anyway so nevermind. --Alexandr Dmitri (talk) 23:11, 10 August 2010 (UTC)
- I like splitting things into the subpages (definitely for archives it is a lot better). I dislike the notable works section. We are still a small enough community that anyone who is voting should already have a decent idea what the person has contributed and so it just adds clutter. Likewise "RfAs for this user" is unnecessary. Most RfAs pass, so a user with past RfAs would be a oddity rather then something worth including in a template. Finally RfAs are not votes, dividing them up into sections like that encourages them to be treated as votes. --Cspurrier (talk) 01:14, 11 August 2010 (UTC)
-
- I find that I like splitting the archives into subpages for each request, but I oppose separate subpages for requests that are still open. Requests should be entirely on the RFP page until they are actually archived and thus cease to be visible on the page.
-
- One thing we might do better is that, when an archive box is placed around a discussion, the box should start just below the section heading, instead of above. That makes it easier both to edit the previous section (which thus doesn't have the top of the following archive box in it), and to archive the closed section (which thus doesn't require editing the whole page).
-
- My reasoning on open-request subpages:
- For anyone who watches RFP, open-request subpages make it easier to not follow the progress of each request than to follow it. That's just backwards from what we now want on Wikinews: we have a small community, and anyone who is watching RFP at all will probably want to follow the progress of each request.
- The only upside I can think of to open-request subpages is that, if there are multiple requests open at once, they all have subsections with the same names; so if someone edits a subsection directly, you can't tell from the edit summary which request they were addressing (and it often isn't obvious from the diff, either). I edit the whole request section, so that the edit summary will identify the discussion.
- Open-request subpages make starting a request more complicated.
- Once someone has added an open-request subpage to their watchlist, if they want to keep their watchlist trim they'll have to remember to unwatch the subpage later.
-
- If closure of the discussion gets undone —which has happened recently— anyone who had already unwatched it will simply not know that it has been reopened. I can think of several solutions to that, but the only one that doesn't involve a higher level of red tape is to simply not have open-request subpages in the first place.
- Wikibooks, with a participating project-wide community smaller than ours, puts RFDs on a single page (even though there are always more of them open than I ever remember us having open RFPs). Once each discussion is closed, it is moved to a separate page, and transcluded on the main page for a while before the transclusion is removed. That seems to work pretty well — although they don't divide each RFD into subsections. (Keeping a chronological list of archived requests would improve their system, I think; maybe I'll have time to set that up, at some point.)
- My reasoning on open-request subpages:
-
- (Postscript: Many of these problems would disappear if the wiki software provided a way to watch a page and all its subpages, so that new subpages get watched automatically. That's quite interesting to me, because Wikibooks has been wishing for such a feature for years.) --Pi zero (talk) 16:19, 11 August 2010 (UTC)
Crazy idea
Is it possible to create a userright, like mini-reviewer or something, that can:
- Automatically mark revisions in non-main namespaces patrolled (autopatrolother)
- Edit semi-protected pages (autoconfirmed)
- Revert many editions made by the same editor in a row (rollback)
- Have the editor's own edited marked as sighted if the version immediately before it is sighted
But cannot
- Sight pages that currently need to be reviewed
- View list of unreviewed pages (unreviewedpages)
- View recent changes patrol marks (patrolmarks)
If such a right is created, I'll be the first to apply. :) Kayau (talk · contribs) 07:04, 15 August 2010 (UTC)
- We don't use autopatrol. Why would a user account need autoconfirmed? You get it after like 4 days anyways. Rollback is generally not given out so freely. "Autosight" has been removed for everyone (much to my displeasure). So in short: No. --ShakataGaNai ^_^ 07:08, 15 August 2010 (UTC)
- (edit conflict)Currently even reviewers don't have "Have the editor's own edited marked as sighted if the version immediately before it is sighted" (only bots have it atm). You're already autoconfirmed, and I don't even think we use patroller, so I'm not sure what the benefit would be. (other than perhaps rollback, which to be honest isn't that useful imo, but isn't that dangerous. I wouldn't be opposed to just giving rollback to all autoconfirmed users). What is it that you want to do that you can't currently do? Bawolff ☺☻ 07:10, 15 August 2010 (UTC)
- No, per Shaka-Shaka Diego Grez return fire 16:23, 19 August 2010 (UTC)
- If they aren't automatically sighted, then can they at least manually sight their own edits if the revision immediately before it is sighted? I believe they can. My idea is somewhat similar to that of level 1 of w:Wikipedia:Pending_changes#Description. Autoconfirmed people cannot sight others' edits but can sight their own if the revision immediately before it is accepted. Kayau (talk · contribs) 09:05, 21 August 2010 (UTC)
- That —the ability to sight one's own edit if the immediately preceding revision was sighted— is not a lesser responsibility than reviewing. It is reviewing. It requires judgment just as expert and mature as publishing an article. A small edit can be a factual error, copyvio, POV, or otherwise a violation of the style guide. Don't fall into the trap of imagining that there are "minor good-faith edits", such as Wikibooks or Wikipedia might recognize, that should be let through because it's better for the project to encourage contributors and let any resulting problems be ironed out in the long run. That's alien to the nature of what we do on Wikinews. --Pi zero (talk) 14:22, 21 August 2010 (UTC)
- If they aren't automatically sighted, then can they at least manually sight their own edits if the revision immediately before it is sighted? I believe they can. My idea is somewhat similar to that of level 1 of w:Wikipedia:Pending_changes#Description. Autoconfirmed people cannot sight others' edits but can sight their own if the revision immediately before it is accepted. Kayau (talk · contribs) 09:05, 21 August 2010 (UTC)
- No, per Shaka-Shaka Diego Grez return fire 16:23, 19 August 2010 (UTC)
- (edit conflict)Currently even reviewers don't have "Have the editor's own edited marked as sighted if the version immediately before it is sighted" (only bots have it atm). You're already autoconfirmed, and I don't even think we use patroller, so I'm not sure what the benefit would be. (other than perhaps rollback, which to be honest isn't that useful imo, but isn't that dangerous. I wouldn't be opposed to just giving rollback to all autoconfirmed users). What is it that you want to do that you can't currently do? Bawolff ☺☻ 07:10, 15 August 2010 (UTC)
wikt:MediaWiki:Gadget-WiktSidebarTranslation.js
It would be elegant to import this gadget, especially for those who have never installed any additional fonts. It just translates the interwiki links into English, you can test it by ticking it here. JackPotte (talk) 09:16, 19 August 2010 (UTC)
- I'm not really sure if its relevant here. I'd like people to show interest before importing it. Bawolff ☺☻ 17:36, 19 August 2010 (UTC)
- Why not? Diego Grez return fire 20:53, 19 August 2010 (UTC)
-
-
- It could be useful for checking interwikis before sighting them. Blood Red Sandman (Talk) (Contribs) 20:54, 19 August 2010 (UTC)
-
-
-
-
- Does it resolve a known problem or issue? the point is, en.wikinews is already loading a large collection of scripts and (worse!) script libraries which do not do anything 99% of the time. For edge-case users (specialty browsers for disability, old hardware, poor or per-kb-billing internet connectivity, old browsers, etc.) this is already a burden, and should not be added to unless there is a demonstrated need. - Amgine | t 14:27, 21 August 2010 (UTC)
-
-
-
-
-
-
- A better solution to that problem might be to kill off some of the crap... Blood Red Sandman (Talk) (Contribs) 19:59, 23 August 2010 (UTC)
-
-
-
- How many o the gadget goodies could be done away with, or moved server-side as PHP? --Brian McNeil / talk 20:29, 23 August 2010 (UTC)
Reviving the project
Hello all,
If you remember me, I was an active sysop here in 2009, but then took a year-long break from all Wiki activities in August of last year. I have since returned, and am quite shocked of the events that have transpired on this site over the past few months. It seems as though the level of civility here and its collaborative, friendly nature has essentially disappeared. This is definitely not the Wikinews that I remember.
To make things short, I believe that we need to revive and expand this project. English Wikinews is slowly dying, and something needs to be done about it. So, I think that in a project-wide collaboration, there needs to be some sort of effort to change what is wrong; attracting more readers and writers, setting new policies about civility, and making Wikinews an overall better place.
I'll let discussion about this start, but I must make the point clear that we need to:
- a) Outline our problems
- b) Attain more writers
- c) Make the site seem open and friendly
- d) Enforce new policy on civility.
I hope we have interest in this, because it is just what we need.
Cheers,
red-thunder. 16:40, 22 August 2010 (UTC)
- Unless the project is Lazarus (or Spock), revival will be pretty difficult, but here are my ideas:
- I think one of the primary things we should do would be to write more in-depth, collaborative (preferably OR) pieces, rather than many 3-paragraph stubs. The wiki format lends itself well to this format, and there is no way we can compete with the mainstrem media in terms of volume—in terms of depth of coverage, however, we have an advantage. Of course, collaborative articles will not work unless we have a clear civility policy (not necessarily of the kind that has been proposed before, but we need something). Δενδοδγε τ\c 17:03, 22 August 2010 (UTC)
- Agreed. Wikinews needs in addition to new civility policies, an "in-depth"-ization of our articles. As Dendodge says, most of our articles are really, really short. Diego Grez return fire 17:28, 22 August 2010 (UTC)
As a semi-active newbie, I believe that it is in fact rather unsurprising that Wikinews is more likely to be affected, as a whole, by conflicts than Wikipedia or Wikibooks. I apologise if this is POV-pushing, unconstructive, or something-the-community-has-already-discussed-on-anyway-only-I-was-unaware-of-it, but here it goes anyway.
- Wikipedia is a project with more sub-communities than there are active users on WN. Different communities have different atmospheres. Some communities are small and consist of people who always agree with each other. Those projects are happy. Some communities are medium and consist of people who regularly disagree with each other. Some communities are big and contain communities that are small or medium. Each of these communities have some people who are, in Pi zero's words, in the 'project-wide cell'. Some people are in the 'project-wide cell', but not any other community, perhaps because they are not interested in mainspace work. Due to the complexity of Wikipedia, if one community disappears, there are still lots of others. Therefore, Wikipedia is not likely to become an overall unfriendly place due to conflicts and disagreements.
- Wikibooks is a project whose number of active users is considerably larger than Wikinews (which again is something Pi zero discovered). (Note here, that Thenub's CU discussion has more supports than WN ArbCom discussions.) Most active regular contributors only care about their own books. And, at any given point of time, no book has more than two active contributors. Really. So there isn't much room for book-specific disputes. As for the 'project-wide cell', it is very small. Some users are here today and gone tomorrow, and then back a month later, then goes again. Due to its size, it is not as often (note that I'm not saying NEVER, which is a completely different thing!) vulnerable to destruction due to disputes. A dispute can also be here today, and gone tomorrow. Therefore, Wikibooks, due to its small 'project-wide cell', is again less likely to become an overall unfriendly place due to conflicts and disputes.
- Wikinews is different. Instead of having loads of sub-communities etc, it has one large project-wide cell. Wikinews is like a city; Wikibooks, on the other hand, is a suburb. (Not a very good metaphor, but you get the idea right? :P) Everyone does pretty much the same job. Because all the people are packed together, they start having disputes. It can be nothing at first, but grudges grow, and eventually burst. People leave the city and go somewhere else. This is the problem with Wikinews. Is it possible to divide the community so that there are people working only on one topic? I think not; some people work on, say, Chile, and other people work on, say, um, well, global warming, UFOs, and all those. So that won't work. This is why, IMO, Wikinews is more vulnerable to destruction due to disputes.
I know some of my arguments are rather weak, and that I have not really followed any logical order, and that I expressed myself in rather awkward manners. I will also note that I, as a kid, don't know that much about the world. But this is my opinion, and I have given it, regardless of consequences. Kayau (talk · contribs) 11:29, 23 August 2010 (UTC)
- I think Wikipedia has a much greater tendency towards drama than Wikinews, but I do agree that when there is a dispute here it affects the whole community. Δενδοδγε τ\c 11:45, 23 August 2010 (UTC)
Geo-tagging
Wouldn't it be amazing to be able to go to the main page and see a nice little map of where all the news in the whole world is? Also you could see what's the news in a certain area off the bat. Also some important news happens in un-known areas. Instead of having a lame little .svg map you could explore the area in depth in Google maps. I'm pretty certain we can hack the Google Maps API to allow this. Also their is already a template to deal with this ({{location}}) What are your guys thoughts on this?
Note - We can use Google maps as their TOS states "The Maps API is a free service, available for any web site that is free to consumers. Please see the terms of service ( http://code.google.com/apis/maps/terms.html ) for more information." - If you guys hate Google we could always use http://www.openstreetmap.org/ but they offer less features
Irunongames•play 00:05, 23 August 2010 (UTC)
- I'm liking this idea a lot. Not something you usually see on news sites, very unique. red-thunder. 18:11, 23 August 2010 (UTC)
- It is not the Google Maps ToS that you should be concerned about. Should it be implemented as an integrated part of Wikinews, we will be instructed to take it out immediately. The WMF is very, very keen to avoid sharing data without readers being aware of such. OpenStreetMap,... maybe. Google? Not a chance. --Brian McNeil / talk 20:22, 23 August 2010 (UTC)
-
- Wikiminiatlas? Also the foundation people seem to like the open street map people, so if this was to happen I'd put my money on it being with open street map, not google. Bawolff ☺☻ 22:05, 23 August 2010 (UTC)
- Anyone who remembers mentions of using Google Analytics will know exactly why their APIs are unlikely to be used without special treatment for the WMF. --Brian McNeil / talk 22:26, 23 August 2010 (UTC)
-
- Do we need special treatment? We can easily set up a API and since the WMF makes no money off Wikinews it will be no issue Irunongames•play 00:51, 24 August 2010 (UTC)
- Wikiminiatlas? Also the foundation people seem to like the open street map people, so if this was to happen I'd put my money on it being with open street map, not google. Bawolff ☺☻ 22:05, 23 August 2010 (UTC)
┌────────────────┘
We cannot set up an API, because it involves making readers submit to Google ToS in terms of what data they collect, and how they use it . That is not a decision that can be made by anyone here; you add Google code, that isn't clearly, and unambiguously, requiring of a conscious activation step, you're breaching the WMF Privacy Policy. You will be reverted. Now, look to the alternatives, please. --Brian McNeil / talk 01:05, 24 August 2010 (UTC)
- WikiMiniAtlas looks like the best bet to me—it is already widely used on Wikipedia, and shouldn't be too hard to adapt for our purposes. Δενδοδγε τ\c 19:53, 24 August 2010 (UTC)
Changing how we handle shorts
At present our handling of shorts is less then ideal. It is impossible to find a short in a category other then by guessing. Search has gotten better, but is still handles them poorly. RSS and Twitter display them oddly as well. You also have no idea what the shorts are going to be before you click on it.
I would like to propose making the following changes:
- All shorts sections would be their own articles
- We tag them with a category that we exclude from the normal list on the main page
- We add a section to the main page (below the normal articles?) that we dpl in the days shorts
These changes fix all of the problems I listed above and also make reviewing much easier (only have to review one section at a time). Secondary benefits include making our coverage appear to be more comprehensive and encouraging more people to write shorts via better exposure (and with luck eventually graduate into writing full articles). Thoughts?--Cspurrier (talk) 01:02, 23 August 2010 (UTC)
- Oh yes! This should stop good shorts getting stuck in review treacle.
- Let's have a distinctive headline style, to set expectations in headline feeds, search results and portals. I propose starting each one with "Brief: " such as,
- Brief: General Motors recalls 243,000 crossover vehicles
- --InfantGorilla (talk) 10:03, 23 August 2010 (UTC)
-
- Suggest "In brief:" or "In short:". Note that any en.WN article may also have a short; if a standard practice were to write a single paragraph short, it could also serve as the lede for news articles (although that would entail more work in maintaining the short for articles which are still developing.) - Amgine | t 05:43, 25 August 2010 (UTC)
-
-
-
- I like your (Amgine's) suggestion for the headline.
- Why not copy and paste the short into the lede of an expanded article? Then the short would be frozen in time, while the expanded article would be developed and published a few minutes or many hours later, by which time the opening paragraph would look a little different.
- (It would be nice to have a forward link from the short to the in-depth version, but that is for a different discussion)
- Shorts can also be used for brief updates on an existing full article. For example last month we published a story about a writer who was arrested by Singapore police. 48 hours later he was bailed, which was an important update, but not enough for a full article. It would have made a good short if we could get it out quickly (rather than wait a day or two for a 'shorts' combo with 2 unrelated stories) and would be helpful to show in the news feed. In the end, the release on bail was never reported by Wikinews (though I did mention it in 'Opinions') but nearly all other outlets that covered the original story reported the release.
- --InfantGorilla (talk) 12:54, 25 August 2010 (UTC)
-
-
New gadget: the subtitles in the videos
Bugzilla are inviting us to put this gadget allowing to see the subtitles with the videos (already installed at least on en.w, fr.w, fr.b, fr.v & Commons) directly in Mediawiki:Common.js. Actually, they need some feedback. JackPotte (talk) 13:04, 25 August 2010 (UTC)
Restart page reformat thread
OK, so I think consensus is that the page redesign concept proposed way above is a good idea. User talk:Dendodge/Sandbox has what it currently looks like.
As discussion has mostly ended above, I'm now wondering, when does everyone want to implement this? In a month, or over a couple months? Do a trial run on a few new articles first? I know brianmc had written out plans for a much longer roadmap, and this could very well kickstart some of those other items. —fetch·comms 22:38, 27 August 2010 (UTC)
- Go ahead. I just did one at User:Fetchcomms/test2 and I think it looks fine. Can you try on a shorterish article, to compare? I've also added more params to the template. —fetch·comms 15:14, 28 August 2010 (UTC)
- Care to move the template to the template namespace? I'll do the leads, if that's fine. —Mikemoral♪♫ 15:18, 28 August 2010 (UTC)
- Set up a comment/bug report space. —fetch·comms 15:39, 28 August 2010 (UTC)
- Yep, just had to use #tag. —fetch·comms 15:49, 28 August 2010 (UTC)
- Can someone semi Template:Page layout, as vandalism would affect a whole article now, not just a small bit. —fetch·comms 15:56, 28 August 2010 (UTC)
Glenn Beck to hold controversial 'Restoring Honor' rally at Lincoln Memorial looks pretty good to me, and nobody has hated it enough to complain yet, so that can only be a good thing. If the trial goes well, someone (looks at Bawolff) will have to make a couple of changes to the review gadget (and possibly MakeLead, but I'm not sure) to handle the new format before we roll it out completely. Δενδοδγε τ\c 16:00, 28 August 2010 (UTC)
- If anyone wants to use the template for a few other new articles, that might get us more feedback. —fetch·comms 16:41, 28 August 2010 (UTC)
- I'll give you some feedback :) A major change like this needs to be made a little more public, so users can comment on it before it happens. The new design is not particularly appealing, and I for one will not use it on any articles I create. I don't read the cooler that often, so probably a sitenotice or something for the future, ok? BarkingFish (talk) 23:42, 28 August 2010 (UTC)
New Main Page Proposal
Hi all, I have created a new main page proposal that I think eliminates a lot of whitespace currently present and organizes it more. The proposal is here. Please leave feedback on the talkpage, I would love to get this implemented! red-thunder. 01:35, 2 September 2010 (UTC)
Assistance
|
|
St. Louis area
How can I find out if people need photography help in the St. Louis area? If a Wiki reporter plans to cover something in the area, I might be available to photograph it for them. Do we have a "dark room" somewhere to help reporters link up with photographers? Rklawton (talk) 20:52, 17 August 2010 (UTC)
Vicious circle in Talk:Wikinews interviews William Pomerantz, Senior Director of Space Prizes at the X PRIZE Foundation
Hi, can anyone please help me there? I want to do it according to wikinews rule, but it seems noone seems to be responsible to solve this! best regards, --Andreas -horn- Hornig (talk) 17:55, 21 August 2010 (UTC)
how do I cite the TV
How do I cite the TV? Quick - this is breaking news! Kayau (talk · contribs) 13:46, 23 August 2010 (UTC)
Story idea: Examiner.com 2.0 transition
I am a citizen journalist on Examiner.com. That site has been going through a fairly massive and rather problematic system & formatting overhaul. Many of its editors are taking a "wait and see" approach until authoring more content for publication. I have learned this from e-mails, teleconferences that include staff and writers, and just watching the bug report page.
Two questions:
(1) Am I too "close" to this situation to report on it objectively? Are my personal experiences and sources sufficient for an article here?
(2) Is this matter even newsworthy? As far as I know, no mainstream media have picked up on this, because the site to outside readers appears in fair working order, but to insiders (the journalists) it has been a bit of a nightmare.
I look forward to feedback. -- Thekohser (talk) 20:08, 1 September 2010 (UTC)
-
- Yes, but yes.
- Generally, if the news event is discrete, and of interest to larger than a neighborhood. This doesn't seem likely to meet the latter element; it would likely be of interest only to the 'insiders'.
- Just my opinions. - Amgine | t 02:40, 2 September 2010 (UTC)
-
- Yes, from the wah you put it across, far too close.
- It might be news, I too would question the scope of audience. I am concerned in the way you present this. You imply lots of damning evidence exists. A good journalist would want their side of the story; as well as scope of interest, you give no positive opening to talk to them with. --Brian McNeil / talk 04:59, 2 September 2010 (UTC)
-
-
- Isn't the Portal:Virginia designed with the specific purpose of accommodating this very kind of news report (a report, I note, that hasn't yet been created)? A place for a topic that might be deemed something that is not newsworthy of the Main Page, but yet newsworthy of the Virginia Portal. 24.125.55.90 (talk) 05:26, 2 September 2010 (UTC)
-
Miscellaneous
|
|
Wikimania Scholarships
The call for applications for Wikimania Scholarships to attend Wikimania 2010 in Gdansk, Poland (July 9-11) is now open. The Wikimedia Foundation offers Scholarships to pay for selected individuals' round trip travel, accommodations, and registration at the conference. To apply, visit the Wikimania 2010 scholarships information page, click the secure link available there, and fill out the form to apply. For additional information, please visit the Scholarships information and FAQ pages:
Yours very truly, Cary Bass
Volunteer Coordinator
Wikimedia Foundation —The preceding unsigned comment was added by Bawolff (talk • contribs) 19:16, 5 April 2010
Returned
Hey everyone,
I'm not sure if you remember me, but I'm a sysop here that took a long break almost a year a go. I would just like to inform you that I have returned to normal activity, and am gladly ready to help maintain the site.
Cheers,
red-thunder. 17:18, 21 August 2010 (UTC)
- Welcome back. Diego Grez return fire 17:20, 21 August 2010 (UTC)
Credit for your work on Wikinews
I attended Napier University's Open Day today (well, earlier in the last 24 hours).
When I got an opportunity to speak to one of the lecturers, I introduced myself, cited where examples of my work could be found, and was met with the response, "I recognise your byline".
Apparently, my journalistic work here is something they'd take into consideration and fast-track me into the third or fourth year of a four-year BA (Hons) in Journalism because of.
I raise this here because I know many contributors are near school-leaving age, or might look into similar if there's a possibility of cutting a couple of years off an expensive course.
- Do not ask me for references.
--Brian McNeil / talk 00:59, 27 August 2010 (UTC)
- That's great to hear -- I love it when Wikimedians see doors open because of their work here. -Pete F (talk)
Announcement/invitation
Hi all, I'm wearing my Wikimedia Foundation hat today. You may be aware of our Bookshelf Project: creating collection of materials that help people understand the Wikimedia world and how to start contributing to our projects.
We believe that screencasts—video demonstrations of how to use software—are a great way to reach a wide audience. We have seen some cool examples emerging in the Wikimedia volunteer community and from other sources. But there are some pretty big challenges involved in producing a good screencast, especially if you're on a tight budget and/or want to use free and open source software.
So, we want to create an online tutorial (using screencasts) that helps people get started on producing their own screencasts. And we want to work with the passionate and knowledgable volunteers in our community to produce the best results and lay the groundwork for ongoing resources (perhaps as a WikiProject) for Wikipedians who want some support in producing screencasts.
Interested? Please visit the Screen Sprint page on the Outreach wiki for more info, and an application to submit by Monday, August 30.
