Issue system: Difference between revisions
→Extensions: useful in a journalism wiki
(→Extensions: useful in a journalism wiki) |
|||
| (2 intermediate revisions by the same user not shown) | |||
| Line 7: | Line 7: | ||
* How can editors better deal with multiple layers of content. At one time, it use to be that a newspaper would edit a story at the end of the day. Now newspapers deal with multiple types of content throughout the day including breaking news updates, blogs and then the traditional story at the end of the day. | * How can editors better deal with multiple layers of content. At one time, it use to be that a newspaper would edit a story at the end of the day. Now newspapers deal with multiple types of content throughout the day including breaking news updates, blogs and then the traditional story at the end of the day. | ||
* Most newspapers, particularity small and mid-sized ones, are short staffed. Related to point one, reporters are often dealing with multiple pieces of content at the same time. Though it is a myth to do "more with less," it is important to find ways to be more efficient in the editing process. | * Most newspapers, particularity small and mid-sized ones, are short staffed. Related to point one, reporters are often dealing with multiple pieces of content at the same time. Though it is a myth to do "more with less," it is important to find ways to be more efficient in the editing process. | ||
**Another perspective is that "short staffed" is a metaphor for "insular, lazy and able to stonewall learning new efficient methods". Most newspapers have lots of eager editorialists (journalism students, frequent letter to the editor writers, activists spin doctors) who could participate in low-risk aspects of the process like finding verifiable sources for key facts | |||
* The editing process is one of the key opportunities for reporters and editors to learn and develop. Unfortunately, in the rush of the 24-hour news cycle, editing has become more rushed. Is there a way to provide insight that can help both the editor and reporter improve? Also, is there a way to promote more front-end editing, which is where the editor discusses with the reporter at the beginning of the reporting process what is necessary for the story? | * The editing process is one of the key opportunities for reporters and editors to learn and develop. Unfortunately, in the rush of the 24-hour news cycle, editing has become more rushed. Is there a way to provide insight that can help both the editor and reporter improve? Also, is there a way to promote more front-end editing, which is where the editor discusses with the reporter at the beginning of the reporting process what is necessary for the story? | ||
| Line 22: | Line 23: | ||
* Eventually, we would like to develop a system that would also allow different areas of the newspaper (i.e. online departments, advertising, etc.) to bring up issues and tasks to each other. For example, if an editor has a problem with the CMS, the editor would be able to log into the system and flag a problem. | * Eventually, we would like to develop a system that would also allow different areas of the newspaper (i.e. online departments, advertising, etc.) to bring up issues and tasks to each other. For example, if an editor has a problem with the CMS, the editor would be able to log into the system and flag a problem. | ||
== What's been done so far == | == What's been done so far, what barriers remain == | ||
*The focus right now is the first two features, in-line editing task annotations and the prioritization of those tasks. | *The focus right now is the first two features, in-line editing task annotations and the prioritization of those tasks. | ||
*David has worked on developing the infrastructure for these two features. | *David has worked on developing the infrastructure for these two features. | ||
| Line 29: | Line 30: | ||
*Mai did a follow-up discussion with David to talk about the challenges of the system. They include: | *Mai did a follow-up discussion with David to talk about the challenges of the system. They include: | ||
**Upfront learning of wiki syntax. It might be a hard sell for older editors to learn code. | **Upfront learning of wiki syntax. It might be a hard sell for older editors to learn code. | ||
***position: Let them use facebook comments in talk pages, then have streamlined workflow to update pages from those, logging in "as" those persons so their contribution shows up as if they themselves had done the job, in the edit summary - when they realize there are potential broken telephone problems with this, they will eventually take over that editing personally | |||
***position: really no alternative to learning mediawiki syntax unless you want the "other side" always editing Wikipedia...? no publicly involved person can afford not to learn it in 2011 | |||
** This system works great if there is plenty of editing time. It works great for a long-form project. But Mai expressed concern whether this system could handle content done in almost real-time, fast paced deadlines. | ** This system works great if there is plenty of editing time. It works great for a long-form project. But Mai expressed concern whether this system could handle content done in almost real-time, fast paced deadlines. | ||
***position:tagging lets others help; Wikipedia handles real time event management very well; Ability to let third parties do the tagging and frame detection and bias detection and proof-reading ultimately makes the entire process work much faster | |||
==What's next== | ==What's next== | ||
| Line 56: | Line 60: | ||
=== Extensions === | === Extensions === | ||
Avoiding custom code saves a lot of effort and focuses on the application instead. | |||
==== Extensions to use as is ==== | |||
*[http://www.mediawiki.org/wiki/Extension:Replace_Text Replace text], required to fix typos across a database - use with care as journalling is imperfect, i.e. changes aren't in history | |||
*[http://www.mediawiki.org/wiki/Extension:Intersection dynamic page list] of most recent changes in a category or union of same | |||
*[http://www.mediawiki.org/wiki/Extension:Treeview Tree view of long lists] | |||
*Parser [http://www.mediawiki.org/wiki/Extension:StringFunctions string functions] to allow the use of looked-up data in pages and [http://www.mediawiki.org/wiki/Extension:VariablesExtension variables] for page-scoped variables | |||
*Structured [http://www.mediawiki.org/wiki/Extension:Data_Transfer Data transfer] and literal [http://www.mediawiki.org/wiki/Extension:External_Data external data] support, reducing the data management load in mediawiki itself and making it easier to integrate legacy systems | |||
*[http://www.mediawiki.org/wiki/Extension:Semantic_Drilldown Semantic Drilldown] lets new users more simply navigate a vast database of semantically tagged data using a more form-like approach; Also [http://www.wikid.eu/index.php/WikID:Extensions Import] text from other wikis. | |||
*[http://www.wikid.eu/index.php/WikID:Extensions Advanced user rights] and [http://mediawiki.org/wiki/Extension:PermissionACL ACL] to deal with contractual or fuddy-duddy concerns about universal page editing - only use permission schemes if being '''''paid''''' to manage them, as they almost always go awry, are overused and cripple a wiki | |||
*[http://mediawiki.org/wiki/Extension:Lockdown per namespace group permissions] useful for very authoritative (policy, user) or contentious (position, faction point of view) namespaces. | |||
* | |||
==== Extensions to extend ==== | |||
*Specialize [http://www.mediawiki.org/wiki/Extension:Replace_Text replace text] to deal with cases like name correction, policy changes on how to spell words with multiple spellings (especially in translations e.g. from Arabic), and journal these better, i.e. record the change properly in some log of universal changes for better accountability | |||
*Specialize the various permissions and rights schemes for editorial roles (publisher, chief editor, reporter, source, etc.) | |||
*Modify the [http://www.mediawiki.org/wiki/Extension:Facebook Extension:Facebook] to not just "like/unlike" but mark a statement as having a given frame or just having a "bad frame", noting a "position" or providing citable evidence or etc. | |||
*Modify the [http://www.mediawiki.org/wiki/Extension:Semantic_Project_Management Extension:Semantic_Project_Management] to support multiple perspectives or frames on priorities, "what must be done"; When dealing with management of priorities in a collective, people can then organize into factions and vote (especially allocation-vote) on what needs attention. For both that purpose and identification of frames/POV/bias, consider | |||
*Support a [http://www.dkosopedia.com/wiki/Red_Green_Blue_Wings chromatic space model] rather than left/right model of framing | |||
*Extend the various rights and permissions frameworks to deal with voluntarily-allied user factions of similar views/POV, giving them their own "party" and namespace to develop views and filters (for instance, omitting certain authorities they do not trust) | |||
==== Entirely new extensions to propose and perhaps create ==== | |||
*A general attribution tool to attempt to identify the ultimate authority or authorities cited by sources advancing claims, especially to determine whether a large number of reports are ultimately relying on a single source and therefore fragile | |||
*Specific to Canada and its abusive libel laws: A libel analysis tool to look through an archive for potentially defamatory words and claims, or suspect sources that may have made false factual statements quoted, and prioritize the tasks defined in law to claim a [[reportage defense]]. Sensitive to suit filing deadlines, e.g. three months Ontario , 2 years BC to reliably report when the right to sue on given material would be denied, when it passes certain publication thresholds of readership (important to prove jurisdiction), etc. | |||
{{Subject | {{Subject | ||