Issue system - Revision history

142.177.107.66: /* Extensions */ useful in a journalism wiki

2011-02-20T13:47:46Z

Extensions: useful in a journalism wiki

@@ Line 60: / Line 60: @@
 === Extensions ===
-**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.
+Avoiding custom code saves a lot of effort and focuses on the application instead.
 {{Subject

142.177.107.66: /* Why this functionality matters */ "short staffed" is a metaphor for "insular, lazy and able to stonewall learning new efficient methods".

2011-02-20T10:49:01Z

Why this functionality matters: "short staffed" is a metaphor for "insular, lazy and able to stonewall learning new efficient methods".

← Older revision		Revision as of 10:49, 20 February 2011
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?

142.177.107.66: /* What's been done so far, what barriers remain */ and suggestions on debates

2011-02-20T10:45:18Z

What's been done so far, what barriers remain: and suggestions on debates

← Older revision		Revision as of 10:45, 20 February 2011
Line 22:		Line 22:
	* 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 29:
	*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==

142.177.107.66: /* Proposed features */

2011-02-20T10:40:53Z

Proposed features

← Older revision		Revision as of 10:40, 20 February 2011
Line 43:		Line 43:
	==Proposed features==		==Proposed features==

	*integrate with the more conventional task/project infrastructure that [[Creative Commons]] developed [http://www.mediawiki.org/wiki/Extension:Semantic_Project_Management for semantic project management], [wiki.creativecommons.org/CcTeamspace originally CcTeamspace]		*integrate with the more conventional task/project infrastructure that [[Creative Commons]] developed [http://www.mediawiki.org/wiki/Extension:Semantic_Project_Management for semantic project management], [http://wiki.creativecommons.org/CcTeamspace originally CcTeamspace]
	*rapid import and integration with [[facebook issue]] groups, especially those taking strong positions on certain issues - critical to engage persons who have already expressed an issue; especially, import of links posted to those groups with some tagging		*rapid import and integration with [[facebook issue]] groups, especially those taking strong positions on certain issues - critical to engage persons who have already expressed an issue; especially, import of links posted to those groups with some tagging
	*import/export of [[issue/position/argument]] [http://www.dkosopedia.com/wiki/Issue/position/argument] pages possibly including [http://openpolitics.ca/libel tikiwiki, popular in Canada for issue debate] - which can be more easily edited in more standard mediawiki format; make it easier to extend to [http://www.dkosopedia.com/wiki/Issue/position/argument/evidence/source/authority deeper formats]		*import/export of [[issue/position/argument]] [http://www.dkosopedia.com/wiki/Issue/position/argument] pages possibly including [http://openpolitics.ca/libel tikiwiki, popular in Canada for issue debate] - which can be more easily edited in more standard mediawiki format; make it easier to extend to [http://www.dkosopedia.com/wiki/Issue/position/argument/evidence/source/authority deeper formats]
Line 57:		Line 57:

	**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: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		**Support a [http://www.dkosopedia.com/wiki/Red_Green_Blue_Wings chromatic space model] rather than left/right model of framing

142.177.107.66: /* Proposed features */

2011-02-20T10:34:55Z

Proposed features

← Older revision		Revision as of 10:34, 20 February 2011
Line 45:		Line 45:
	*integrate with the more conventional task/project infrastructure that [[Creative Commons]] developed [http://www.mediawiki.org/wiki/Extension:Semantic_Project_Management for semantic project management], [wiki.creativecommons.org/CcTeamspace originally CcTeamspace]		*integrate with the more conventional task/project infrastructure that [[Creative Commons]] developed [http://www.mediawiki.org/wiki/Extension:Semantic_Project_Management for semantic project management], [wiki.creativecommons.org/CcTeamspace originally CcTeamspace]
	*rapid import and integration with [[facebook issue]] groups, especially those taking strong positions on certain issues - critical to engage persons who have already expressed an issue; especially, import of links posted to those groups with some tagging		*rapid import and integration with [[facebook issue]] groups, especially those taking strong positions on certain issues - critical to engage persons who have already expressed an issue; especially, import of links posted to those groups with some tagging
	*import/export of [[issue/position/argument]] pages - which can be more easily edited in more standard mediawiki format		*import/export of [[issue/position/argument]] [http://www.dkosopedia.com/wiki/Issue/position/argument] pages possibly including [http://openpolitics.ca/libel tikiwiki, popular in Canada for issue debate] - which can be more easily edited in more standard mediawiki format; make it easier to extend to [http://www.dkosopedia.com/wiki/Issue/position/argument/evidence/source/authority deeper formats]
			*means of identifying [http://www.dkosopedia.com/wiki/MemeTank popular memes] without judging or analyzing them (yet) and developing editorial policy statements about them or level of [http://www.dkosopedia.com/wiki/Ontological_warfare ontological warfare] going on
			*Features required of an [http://let.sysops.be/wiki/Explicitly_political_public_wiki explicitly political public wiki] which may be further debated in a Canadian context in [[this wiki]]: [[explicitly political public wiki]], most of which are in common with journalism, but with the complexity that many frames or POV must be explicit. To that end especially consider:
	*create a [[position:namespace]] to differentiate what might be taken as positions of the wiki as a whole (like "2010/G20 and G8 Budget/Summit costs were unreasonable" [http://canbudget.zooid.org/wiki/2010/G20_and_G8_Budget/Summit_costs_were_unreasonable] which is highly opinionated and not obviously anything other than evidence of editorial bias, while "position:2010/G20 and G8 Budget/Summit costs were unreasonable" is much more obviously NPOV).		*create a [[position:namespace]] to differentiate what might be taken as positions of the wiki as a whole (like "2010/G20 and G8 Budget/Summit costs were unreasonable" [http://canbudget.zooid.org/wiki/2010/G20_and_G8_Budget/Summit_costs_were_unreasonable] which is highly opinionated and not obviously anything other than evidence of editorial bias, while "position:2010/G20 and G8 Budget/Summit costs were unreasonable" is much more obviously NPOV).
	*semantically differentiate a particular short-term "debate" from the longer term "issue" framing persistent over time (most "debates" are short lived and "decided", while "issues" can sometimes be persistently argued for thousands of years and allow for many re-framings, e.g. democracy vs. autocracy, humanitarian vs. indirect operational views of economics, etc.)		*Means of [http://www.dkosopedia.com/wiki/Bad_frame bad frame] detection, and other explicit semantic frames so that positions may be identified and issues neutrally stated, [http://www.dkosopedia.com/wiki/Trite_Terminology trite terminology] dismissed,
	*a [[frame:namespace]] to differentiate arguments about the frame itself, and agree on labelling standard for certain POV - Dkosopedia is quite advanced at cataloguing frames.		**semantically differentiate a particular short-term "debate" from the longer term "issue" framing persistent over time (most "debates" are short lived and "decided", while "issues" can sometimes be persistently argued for thousands of years and allow for many re-framings, e.g. democracy vs. autocracy, humanitarian vs. indirect operational views of economics, etc.)
			**a [[frame:namespace]] to differentiate arguments about the frame itself, and agree on labelling standard for certain POV; Dkosopedia is quite advanced at [http://www.dkosopedia.com/wiki/ThinkTank political semantics] esp. cataloguing frames:
			**[http://www.dkosopedia.com/wiki/Practical_Frames Practical frame] support, noting [http://www.dkosopedia.com/wiki/Category:Framing current framing problems] relevant to Canadian journalism, of which there are many, e.g. "Oil Sands vs. Tar Sands", "GDP as prosperity", "subsidies in Internet access", "subsidies to political parties" and so on.

			=== Extensions ===

			**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.
			**Support a [http://www.dkosopedia.com/wiki/Red_Green_Blue_Wings chromatic space model] rather than left/right model of framing



	{{Subject		{{Subject

142.177.107.66: semantic project management, issue/position/argument, facebook

2011-02-20T10:03:28Z

semantic project management, issue/position/argument, facebook

← Older revision		Revision as of 10:03, 20 February 2011
Line 40:		Line 40:

	* Once those two features are working, we will begin work on integrating other features.		* Once those two features are working, we will begin work on integrating other features.

			==Proposed features==

			*integrate with the more conventional task/project infrastructure that [[Creative Commons]] developed [http://www.mediawiki.org/wiki/Extension:Semantic_Project_Management for semantic project management], [wiki.creativecommons.org/CcTeamspace originally CcTeamspace]
			*rapid import and integration with [[facebook issue]] groups, especially those taking strong positions on certain issues - critical to engage persons who have already expressed an issue; especially, import of links posted to those groups with some tagging
			*import/export of [[issue/position/argument]] pages - which can be more easily edited in more standard mediawiki format
			*create a [[position:namespace]] to differentiate what might be taken as positions of the wiki as a whole (like "2010/G20 and G8 Budget/Summit costs were unreasonable" [http://canbudget.zooid.org/wiki/2010/G20_and_G8_Budget/Summit_costs_were_unreasonable] which is highly opinionated and not obviously anything other than evidence of editorial bias, while "position:2010/G20 and G8 Budget/Summit costs were unreasonable" is much more obviously NPOV).
			*semantically differentiate a particular short-term "debate" from the longer term "issue" framing persistent over time (most "debates" are short lived and "decided", while "issues" can sometimes be persistently argued for thousands of years and allow for many re-framings, e.g. democracy vs. autocracy, humanitarian vs. indirect operational views of economics, etc.)
			*a [[frame:namespace]] to differentiate arguments about the frame itself, and agree on labelling standard for certain POV - Dkosopedia is quite advanced at cataloguing frames.

	{{Subject		{{Subject

199.166.207.144 at 16:39, 7 October 2010

2010-10-07T16:39:56Z

← Older revision		Revision as of 16:39, 7 October 2010
Line 40:		Line 40:

	* Once those two features are working, we will begin work on integrating other features.		* Once those two features are working, we will begin work on integrating other features.

			{{Subject
			\|Topic=Integrated semantic discourse systems
			\|Project=Integrated semantic discourse systems
			\|Description=Using a wiki and issue tracking in journalism workflow
			}}

199.166.207.144: /* What's been done so far */

2010-10-07T16:38:39Z

What's been done so far

← Older revision		Revision as of 16:38, 7 October 2010
Line 24:		Line 24:
	== What's been done so far ==		== What's been done so far ==
	*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~~, who is very skilled at developing wikis,~~ has worked on ~~providing~~ the infrastructure for these two features.		*David has worked on developing the infrastructure for these two features.
	*David has worked with Mai to determine how these annotations can work within her existing work flow.		*David has worked with Mai to determine how these annotations can work within her existing work flow.
	*Mai has had the opportunity to test out the system. David provided a short writing sample for Mai to edit. Mai in turn put her edits on the writing system.		*Mai has had the opportunity to test out the system. David provided a short writing sample for Mai to edit. Mai in turn put her edits on the writing system.

Maiphoang: /* What's next */

2010-10-06T04:56:41Z

What's next

← Older revision		Revision as of 04:56, 6 October 2010
Line 33:		Line 33:
	==What's next==		==What's next==
	* The focus is to improve on the task annotations and the priority of those annotations:		* The focus is to improve on the task annotations and the priority of those annotations:
			**Mai will continue to bring up and discuss concerns about this system, particularly its effect on existing editing process.
	**David will continue to adjust the wiki infrastructure to address concerns.		**David will continue to adjust the wiki infrastructure to address concerns.
	**Mai will continue to test those two features under different mock situations.		**Mai will continue to test those two features under different mock situations.

Maiphoang: /* Features of this functionality */

2010-10-06T04:55:03Z

Features of this functionality

← Older revision		Revision as of 04:55, 6 October 2010
Line 12:		Line 12:

	==Features of this functionality==		==Features of this functionality==
	* In-line editing task annotations. Instead of waiting for the editor to complete editing a story, an editor can go and flag changes (tasks) that need to be made. ~~For example, if~~ the ~~task is to fill holes of information,~~ the editor can go ahead and ~~make those~~ edit ~~requests~~. The reporter ~~could begin editing~~ those ~~aspects of the story~~ while ~~the editor~~ continues ~~to edit the story~~. The reporter could also note when he or she completes the necessary edited tasks~~. This creates more a collaboration rather than the traditional liner process of reporter hands in story - editor asks~~ questions~~/revises - reporter makes the changes~~.		* In-line editing task annotations. Instead of waiting for the editor to complete editing a story, an editor can go and flag changes (tasks) that need to be made. Here's the basic process:
	* Prioritization of editing. ~~The system would provide~~ a page ~~for reporters and editors~~ to ~~see~~ the ~~priority~~ of those tasks.		** The editor receives the content.
	* The ability to directly import the information from the wiki to any content management system. (Ideally, it would ~~be nice~~ if the ~~wiki and the~~ content ~~management system was~~ one ~~in the same, but there is an understand that this isn't always the case~~.)		** The editor reads and begins editing. The editor can go ahead and cite necessary revisions (AP Style, reporting holes, writing issues, etc) within the text.
			** The edit request show up on a list that the reporter can access.
			** The reporter begins to complete those tasks while editing continues. The reporter could also note when he or she completes the necessary edited tasks or ask for follow up questions.
			* Prioritization of editing. As I mentioned, there is a page to view edit requests. Editors would also have the option of prioritizing those tasks. This would work great if the reporter is dealing with multiple types of content at one time.
	* The ability to document at the beginning of the reporting process what is desired for a story (story focus; people to interview; sides to cover). The system would also allow documentation of necessary follow for a story or other piece of content.		* The ability to document at the beginning of the reporting process what is desired for a story (story focus; people to interview; sides to cover). The system would also allow documentation of necessary follow for a story or other piece of content.
			* The ability to directly import the information from the wiki to any content management system. (Ideally, it would be nice if the wiki and the content management system was one in the same, but we know that this isn't always the case.)
	* 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.