Jump to content

Wikipedia talk:Labels/Edit types/Taxonomy

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Notes from pilot labeling

[edit]

The below are some comments/notes we extracted from the pilot run.

  • Add parameter to template
  • Again, not sure any of the edit labels apply to a talk page discussion like this.
  • Archiving a discussion in talk page
  • Bot task
    • Even though this edit is done by a bot, we still want to know what kind of work this bot did for what semantic intention. So, if it is a bot task, please tell us the semantic intention of this edit and what low-level edits are associated with it --Diyiy (talk) 20:11, 12 January 2016 (UTC)[reply]
    • Depends what kind of bot task. Was it archiving a talk page? Was it updating a category link? Maybe bots do work that isn't covered by our intentions/operations. If so, we should extend them I think. --EpochFail (talk • contribs) 14:59, 13 January 2016 (UTC)[reply]
  • Fix image syntax
    • Might need to think of a new category for markup fixes. E.g. you can have a typo in markup and come back to fix it. So, we can have typos in the copy and those get fixed copy-edits. However, typos in the markup may fit into the class of markup-edits, wiki-programming, or markup-fixes. This would be distinct from formatting anything that touches markup in that usually markup is added correctly and it's a specific task to identify problems and fix them. Just like prose is usually added correctly and it's a specific task to identify problems and fix them (copy-edit). --EpochFail (talk • contribs) 14:59, 13 January 2016 (UTC)[reply]
  • GA comment
  • I really wanted to say that the template was being modified.
  • I'm not sure any of the labels really apply to a user talk page discussion.
  • Replace navbox by another one which has more links
    • It could fall under "cleanup". Seems like this might need a new semantic meaning. I imagine that this is some curation work performed at the WikiProject level to improve the quality of a set of articles. --EpochFail (talk • contribs) 14:59, 13 January 2016 (UTC)[reply]
  • talk page -> add comment
  • talk page -> new comment
  • talk page -> new comment
  • talk page message.
  • talk page; add redirect
  • talk-page message
  • This is a page move; none of the labels really apply.
  • User talk page message
  • It seems somewhat limited; like one shouldn't be able to describe every edit using those descriptors. That said, I can't put a finger on what's missing. I think most edits can be sandwiched into those categories, but they are broad enough that I'm not sure they'd all be helpful. Also, sometimes parts of one edit can be described with more than one category (for example, copy-editing an existing paragraph and adding another with new info at the same time), but the solution there is to label for the most significant change. Overall, I don't think it's too difficult.


Please feel free to make any comments to the above notes, and how we could extend our taxonomy :-)

A short summary:

  1. For one revision, one can label it with multiple semantic intentions.
  2. We might want to consider only articles in this stage and will design our taxonomy based on this.

I'm unsure about the newly added semantic intention "Moving a Page". Could we use the reason why a user moves a page to act as the semantic label? "Moving a page" does not sound like a good intention here. --Diyiy (talk) 20:13, 12 January 2016 (UTC)[reply]

Notes inline. --EpochFail (talk • contribs) 14:59, 13 January 2016 (UTC)[reply]

Sentence --> Statement

[edit]

I've been thinking about this for a while. Sentences are the most common types of statements in a Wikipedia article, but there are others. E.g. {{Infobox| ... | population = 502,932}} contains a statement about population. A statement is a basic unit of information. So, should we change "sentence" to "statement" to be more general and inclusive? Maybe we should make the change but someone can think of a better term than "statement" such as "information" (which we used to use). --EpochFail (talk • contribs) 15:52, 13 January 2016 (UTC)[reply]

@EpochFail: Maybe we could borrow some ideas from wikidata:Wikidata:Glossary#Claims and statements? Helder 17:03, 19 January 2016 (UTC)[reply]
@EpochFail @Helder : I see. By "sentence", I mean a line of text; it might involve other components, such as templates, markup, etc, which are available in our syntactic object set. I wonder, if we use the 'Statement' here, will it make this basic syntactic object a mixed one? like a mixture of pure text, template, markup, since statement might be a very complicated line of text? --Diyiy (talk) 04:22, 20 January 2016 (UTC)[reply]
@EpochFail @Helder @Diyiy, I see where you all are coming from but statement is a technical term in Wikidata and I worry people may interpret this in a technical sense as a tuple, which would produce quite the opposite effect. Aaron: in what context are we using this? If it's in the context of the object, I would leave something easily understandable as a "sentence". I wonder if we want to add a generic "data" object applying to factual statements that do not fall clearly under the "number" or "date/time" type.--DarTar (talk) 05:32, 21 January 2016 (UTC)[reply]
DarTar, I think that it is a problem that we have a distinction between "word" and "sentence" but not "paragraph". Also, does changing half of a sentence suggest that I have "modified" a "word" or a "sentence". What does "word" "modification" even look like? The thing I am reaching for here is more like "non-structured-data factual information" at whatever scale (word, sentence, paragraph, section).
Also, per Helder's comment, I think that it actually makes sense to conflate with Wikidata's terminology since it was developed to be a generalized framework for discussing factual statements that provide relationships between structured data and identifiers. That sounds a lot like written language to me. I can't see us confusing Wikipedians into thinking that we expect them to find tuples on Wikipedia, but I think we would like them to think of statements in a structured way -- like tuples.
It seems that no one has commented on going back to the old terminology "information". Why did we make the change to "sentence" and "word" in the first place? --EpochFail (talk • contribs) 14:03, 21 January 2016 (UTC)[reply]
@EpochFail @DarTar: I think 'sentence' here is more general and easier to understand. The distinction between 'word' and 'sentence' is, if you modify only a word, i.e. change a word to its plural form, then it belongs to 'word' modification; but if you change the meaning of a sentence, i.e. do something to neutralize the point of view, then it belongs to 'sentence' modification. By 'statements', i guess we need to explain more to let others know what it means. Also, paragraph is a set of sentences; by putting 'word' and 'sentence' into the syntactic objects, we want to capture minor changes to words and relatively larger changes to a sentence. --Diyiy (talk) 15:04, 22 January 2016 (UTC)[reply]
But if I change a phrase, have I changed the sentence or just two words? Maybe we expect people to label the edit as both Sentence and Word modification. Either way, I'm worried about our ability to consistently apply the labels. Will you draw the same threshold between "word" and "sentence" that I will? Why don't we use [Sentence-Modification] for changing a word in a sentence?
So, another reason I suggest that we consider using "statement" or "information" is that we want to know if new information was added, information was removed, meaning was modified or no change in meaning took place. A [Sentence-Modified] could mean any of those. --EpochFail (talk • contribs) 17:06, 22 January 2016 (UTC)[reply]
Could we define the sentence-word difference in this way? If an edit changes the grammatical structure of a sentence, then it belongs to sentence/structure modification; if it only change words, phrases,etc.. it belongs to word/phrase object. I guess, for 'word', we might want to measure some changes related to surface-level changes, such as word single/plural form, replacement of phrases, etc. If an edit changes the sentence structure that leads to a different parsing tree of this sentence, then it belongs to sentence/structure changes. -- Diyiy (talk) 19:48, 22 January 2016 (UTC)[reply]

Diyiy That doesn't address the point I was making. E.g. one could change a sentence parse tree with or without changing the meaning of the sentence. Also, I'm not sure how we'd formalize this notion of a "parse tree" with our labelers. I think that "inserting", "deleting" and "modifying" meaning/information/factual statements is something we want to be able to capture in our labeling scheme. --EpochFail (talk • contribs) 16:09, 26 January 2016 (UTC)[reply]

Updates Jan 19th

[edit]

For Syntactic Actions, we add the Replacement action [1].

  • Some comments from my own experiences with pilot run: (1) I saw there are several null/empty revisions (no difference for that revision). Should we remove this kind of data for the full run? (2) We might want to refine the words/phrases that appear near the selected semantic intentions.
  • For 'Moving a page' semantic intention, I removed this since this captures the action itself, not the intention of why people move a page.
  • Also, what are we going to do with the "Relocation" performance? It might be associated with 'sentence-insertion' and 'sentence-deletion', but which semantic intention does it belong to? Copy-Editing?
  • I added File to Syntactic Objects.
  • The taxonomy examples are posted here: https://wiki.riteme.site/wiki/Wikipedia:Labels/Edit_types/Examples

--Diyiy (talk) 04:15, 20 January 2016 (UTC)[reply]

Removing "no difference" edits should be straightforward. We can do that by joining to the parent_id and checking for the same sha1. For page moves, we can filter those out too since a simple regular expression can match their automatically generated comments. Should I remove them from the set?
Re. "Relocation" performance, I'm not sure what you are referring to -- maybe a action next to "insert", "modify", "delete"? Either way, we might want an intention for "refactoring" which would suggest much larger changes and moves than a "Copy-edit". --EpochFail (talk • contribs) 15:10, 20 January 2016 (UTC)[reply]
One more note. It seems that "Refactoring" could also fall under "Cleanup". I'm not sure whether we want to limit or extend the meaning of "Cleanup". --EpochFail (talk • contribs) 15:12, 20 January 2016 (UTC)[reply]
I am not sure. It depends whether we want our semantic intention to be mutually exclusive or allow there could be some overlap. --Diyiy (talk) 22:27, 20 January 2016 (UTC)[reply]
I feel "cleanup" is quite ambiguous and messy (pun intended). "Refactoring" and "copyediting" seem more distinctive, if the former is scoped as "moving chunks of text around" (preserving tokens) and the latter is framed as improving the prose/readability of a sentence. Have we considered removing "cleanup" altogether? --DarTar (talk) 05:41, 21 January 2016 (UTC)[reply]
+1. I think that we need a class for doing basic maintenance on an article though. E.g. an edit that updates the nav template to the most recent version, normalizes the spacing between paragraphs, or moves all of the <ref> tags after the punctuation. What semantic meaning would we classify that under now? --EpochFail (talk • contribs) 14:08, 21 January 2016 (UTC)[reply]
Good point. Let's change the cleanup to be 'refactoring'. --Diyiy (talk) 14:55, 22 January 2016 (UTC)[reply]
@EpochFail: I think it might make sense to remove page moves revisions and "no difference" edits. For our first full run, let's focus on edits happened in an article. For Relocation, I saw there are revisions where people move a sentence from the one section to another section. I think we can use "sentence insertion" and "sentence deletion" to capture the Relocation action, and select the intention of why people do this relocation. --Diyiy (talk) 22:25, 20 January 2016 (UTC)[reply]

References

  1. ^ Faigley, Lester, and Stephen Witte. "Analyzing revision." College composition and communication (1981): 400-414.

Descriptions for semantic intentions as verbs

[edit]

I'm going ahead and boldly suggest that we use consistently verbs in the description field for semantic intentions. I'll add the diff here so you can tell me if you like it or not. --DarTar (talk) 05:42, 21 January 2016 (UTC)[reply]

Done, please review.--DarTar (talk) 06:04, 21 January 2016 (UTC)[reply]
Looks good. I think that is much better. --EpochFail (talk • contribs) 14:10, 21 January 2016 (UTC)[reply]

Article as object

[edit]

Do we expect to see changes that coders will want to refer to an article as a whole, i.e. not a single word, sentence, paragraph or section? If so, does it make sense to add "article" or "page" to the list of objects? --DarTar (talk) 05:45, 21 January 2016 (UTC)[reply]

@DarTar There are some changes that happen to an article as a whole. I guess it will involve many smaller actions to a single word, sentence, paragraph or section. Could you give an example where we have to use an 'article' or 'page' object to describe the syntactic action? --Diyiy (talk) 14:53, 22 January 2016 (UTC)[reply]
@Diyiy I don't have an example handy, but I am referring to revisions copyediting or fixing the tone of multiple sentences at once across an entire article. I'll see if I can find a good example.--DarTar (talk) 05:05, 26 January 2016 (UTC)[reply]

Neutralize Point of View vs. Inject Point of View

[edit]

Should we have a distinction in the Semantic meanings between these? Or should we have "Inject Point of View" just fall under "Vandalism"? Another alternative is to drop the "Neutral" and just have "Point of View" that could be used for any POV adjustments. E.g. sometimes the injection of a POV is an application of the WP:NPOV policy because it WP:BALANCE-ing a legitimate opinion/perspective with WP:DUE weight. --EpochFail (talk • contribs) 14:14, 21 January 2016 (UTC)[reply]

@EpochFail: I agree on this. Drop the 'Neutral' and have the 'Point of View' be a semantic intention, and use it for any POV adjustments.--Diyiy (talk) 14:45, 22 January 2016 (UTC)[reply]

Input needed

[edit]

Hey Mdann52 and ONUnicorn. Pinging you because you have been the most active in discussion about this project so far. I just wanted you to be aware of the conversations we're getting into above regarding the taxonomy. It would be great to have your input before we settle on a set of changes and deploy the full labeling campaign. Can you have a look and comment where you think is appropriate? --EpochFail (talk • contribs) 14:19, 21 January 2016 (UTC)[reply]

Replacement action?

[edit]

I don't see what purpose this serves since it could only mean replacement with same. E.g. if one replaces an image with a paragraph, that would require [Image-Deletion] and [Sentence-Insertion]. Why should same types get a special class "replacement"? --EpochFail (talk • contribs) 19:35, 25 January 2016 (UTC)[reply]

Some comments

[edit]

You've asked me to comment, and I do have some thoughts about this.

I almost entirely work only on article improvement, and mainly with improving bad articles to acceptable, not writing new articles or even making major additions of content. I'm looking a these from that perspective--it's different from building a new article.

As for the approach, if you're really going to do this by "grounded theory" we should specify nothing at all, and let people describe edits by the vocabulary they wish, and then try to systematize the corpus. That is not really the way I would naturally approach this problem; I would try to use our experience to get at least trial descriptors in advance, and that seems to be the purpose of the current taxonomy list,.

Semantic intentions (by which I understand what am I trying to do as distinct from why a, I trying to do it. --looking at the list:

  • Copy editing is very different if it is improving grammar, spelling, tone, or punctuation. It can also mean clarifying, removing awkwardness, using a better idiom, applying a special WP style such as not using titles like "Dr." within an article, and so forth. And there's an overlap: changing tone is copyediting, but it can also be improving NPOV. I think of copy editing as anything that is not intended to change the meaning, and that includes many of the other "intentions". There is also the special type of copyediting for consistent national style.
  • Elaboration has an opposite: simplification.
  • Clarification can cover a very wide range of different things -- sometimes copyediting, sometimes fixing factual errors, sometimes updating information.
  • POV can mean simply removing a word that accidentally implies bias, or removing actual bias, or changing the emphasis on different viewpoints, or adding additional viewpoints, I think of them as different
  • Vandalism is a meta-intention, or a purpose., It can include any of the more specific intentions, or just be random nonsense. Unless it is random nonsense, every one of the semantic intentions here can be done for a constructive, controversial, or clearly unconstructive purpose.
  • Removing vandalism similarly--it can be reverting it, or using the opportunity it to also fix things, such as removing wording or sections of an article that encourage vandalism.
  • Refactoring has two meanings -- the small changes involved in Code refactoring or the WP meaning of Wikipedia:Refactoring talk pages which can apply also to articles.
  • Verifiability includes removing unverified text.
  • Formatting includes some much larger things than mentioned--changing from a list to text or a table, or vice versa; It also includes formatting citations.
  • Fact update can be trivial or quite complicated.
  • Link disambiguation is a definite finite type
  • Additionally we have to deal with such edits as nominating for deletion, e,or tagging for a problem. I'd suggest we simply don't includethem in the analysis, but they wiil often be a part of an edit that does other things also.

There's an additional factor :behind the semantic intentions is a purpose-- that is,why the editor is doing this. This can of course be hard to analyze, but it is sometimes obvious or stated in the edit summary. It affects the meaning of many of the semantic factors

  1. trying to fix an article just minimally so it passes afc
  2. trying to fix an article enough to pass afd
  3. trying to fix one particular problem
  4. rewriting probably or certain copyvio to remove the copyvio
  5. rewriting something deliberately in order to give an example to the user -- and often deliberately not fixing everything
  6. trying to correct an error, (which is different from trying to fix a problem)
  7. rewriting a mechanical translation or semi-literate English--which calls for very different sorts of edits than general purpose copyediting
  8. reformatting something so it appears better on the page without changing the information.
  9. Removing promotionalism --what I actually do most.
  10. Repurposing--changing an article so it refers to another aspect or subject, as changing an article on a book to an article about the author.
  11. Code reformatting so the wikitext reads more clearly to facilitate further editing without necessarily intending to change the rendered text at all--for example, adding spaces for clarity-- even it it means reediting it back again later.

there are more specific intentions also--if I add a reference it might be to replace a bad reference or to add an additional one, or to add one where there is none at all; or in fixing a typo I may be fixing a typo I see, or fixing a typo I've made.

  1. trying to be provocative so as to indice someone else to edit-- this can be part of WP:BOLD. It is not necessarily vandalism.

But perhaps all this is more than you want. DGG ( talk ) 05:14, 27 January 2016 (UTC)[reply]

Updates on Jan27th

[edit]
  • Sentence vs. Word: We removed the two from the syntactic objects. Instead, we decided to use 'body copy' to represent any changes performed to the main text
  • Replacement action: we decided to remove this from the action category, since the replacement operation can be captured by deletion and insertion.
  • Wikification: we use this to refer the type of work of linking entities in Wikipedia
  • Meaning: this object in syntactic level is used to provide whether the current edit changes the meaning of article/text or not.
  • Number: we extend the definition of number from numbers to data values, which could include numbers, True/false, or date or time.
  • File: we extend this to include File, Image, Audio, Video, etc..
  • I also modified our taxonomy based on suggestions form DGG, such as adding the Simplification as one semantic intention. I wondered whether Clarification makes sense here, it seems this intention could be captured by other intentions, such as copy-editing, updating information, fixing factual errors. For specify or explain an existing view via adding some extra information, could we merge it to Elaboration?


Thoughts Feb 6th

[edit]

All the semantic intentions could be categorized into two aspects (we do not need annotation for the big aspect; instead, it could be some top level representation):

  • Content Intentions: Elaboration, Clarification, Point of View, Verification, Fact Update
  • Format Intentions: Copyedit, Refactor, Cleanup, Formatting, Link Fix, Link Disambiguation, Wikification
  • Wiki Context Intentions (Others): Vandalism, Anti-vandalism, Process, Other

Our current semantic intention are a bit overlapping; it might be hard for annotator to remember, since this is a flat list..

I propose to add the Simplification, as the inverse to Elaboration, to capture some modification such as pruning or summarization..

Besides, as Ed pointed out, we might want to impose some order on the objects, since some things are real content( regardless of format), others are tags and links, and others are the format(regardless of the content) --Diyiy (talk) 21:57, 6 February 2016 (UTC)[reply]

If possible, could we deploy this taxonomy first to see the basic result? We might iteratively improve our taxonomy through the annotation process? --Diyiy (talk) 21:58, 6 February 2016 (UTC)[reply]

It seems that the general category of "Cleanup" could be used in place of "Simplification". DGG, we're operating from your notes here, so your insight might be best. Do you see any meaningful difference between "Cleanup" and "Simplification" that you'd like to be aware of on an article history page in when reviewing a user's contributions? If so, could you help us describe the different types of edits that would fall into each category? Thanks for all your help. --EpochFail (talk • contribs) 18:43, 7 February 2016 (UTC)[reply]
on wikipedia the terms are used differently: "Cleanup" can really mean almost any type of miscellaneous edits; I use it to mean something more extensive than copyediting, but not as extensive as rewriting. i am not sure all editors make the distinction. Simplification is a type of cleanup. DGG ( talk ) 00:46, 8 February 2016 (UTC)[reply]
Gotcha. It seems that "Cleanup" has a few sub-types: "Simplification", "Clarification", "Point of View", "Copy edit" and "Refactor". If this is right. It seems that "Cleanup" should be renamed to "General cleanup" and any cleanup activity that doesn't fall clearly into these 5 sub-types should be placed under "General cleanup". Does that make sense? --EpochFail (talk • contribs) 15:20, 9 February 2016 (UTC)[reply]
I use "General cleanup" as an edit summary a lot; I think it's a good catchall for things that don't fit into the other subtypes you mentioned. ~ ONUnicorn(Talk|Contribs)problem solving 16:46, 9 February 2016 (UTC)[reply]
Yes, that sounds good to me. DGG ( talk ) 20:38, 9 February 2016 (UTC)[reply]

Simplifying the scheme

[edit]

I am rejoining the discussion after seeing the new proposed categories and being somewhat skeptical about how they are currently scoped. While I do understand what General Cleanup and Wikification are trying to capture, I'd like to recommend that we simplify this scheme dramatically. As a Wikipedian who has been editing on an off for the past 10 years, I'd have trouble applying these 2 categories consistently: they are all defined with reference to other categories (e.g. cleanup that is not X and Y) or they have significant overlap with other categories (e.g. both formatting and wikification cover many types of formatting changes, according to their description). This makes the cognitive cost of applying them very high. If we pooled all these intentions under "Other Intentions" we would lose some discriminatory power but greatly improve the readability of the coding scheme and its portability to other languages. So my proposal, in a nutshell:

  • merge Formatting and Wikification
  • drop General Cleanup and just use the existing categories (including Other)

--DarTar (talk) 20:18, 9 February 2016 (UTC)[reply]

DGG (talk · contribs), EpochFail (talk · contribs), Diyiy (talk · contribs), ONUnicorn (talk · contribs): I'd love your input on the above proposal.--DarTar (talk) 20:21, 9 February 2016 (UTC)[reply]
I'm all for simplifying the scheme; and I like the proposal to merge formatting and wikification; but I'm afraid dropping general cleanup would make "other" too broad. ~ ONUnicorn(Talk|Contribs)problem solving 20:24, 9 February 2016 (UTC)[reply]
I agree on dropping the General Cleanup and merge it with Other Intentions. We have captured several big components of cleanup, and if coders want to provide a category (maybe about cleanup), they could tell it in the 'Notes' box and select 'Others'. --Diyiy (talk) 20:34, 9 February 2016 (UTC)[reply]
I also think 'adding links' is a semantic intention we need to consider. We have link fix, link disambiguation, but where is the link adding? I thought we use Wikification, because "Wikification in computer science, means entity linking with Wikipedia as the target knowledge base". For this sense, formatting seems a bit different with entity linking. --Diyiy (talk) 20:34, 9 February 2016 (UTC)[reply]
I think that we have that under "Wikification", [Wikilink-Insertion] --EpochFail (talk • contribs) 20:35, 9 February 2016 (UTC)[reply]
I have two general concerns. (1) Will this taxonomy have too many categories that is hard for coders to remember and select? (2) Do we need to impose some order on the objects for coders' annotation? For example, if a user insert a sentence with commas, should we consider it as body copy or as both body copy insertion and punctuation insertion? --Diyiy (talk) 20:34, 9 February 2016 (UTC)[reply]
Diyiy (1) is exactly what I am referring to as "cognitive cost" (see for example Menu dependence).--DarTar (talk) 20:37, 9 February 2016 (UTC)[reply]
(EC) I'm in favor of this proposal generally. It seems that Formatting is redundant given that we now have Wikification. I'm curious what ONUnicorn thinks about dropping the "General cleanup" category since we had just discussed it. I propose that we merge "Formatting" under "Wikification" because the latter implies an intention and that we merge "General cleanup" into "Other intention" unless there are substantial concerns raised. --EpochFail (talk • contribs) 20:34, 9 February 2016 (UTC)[reply]
To be more specific with my proposal, I suggest we merge Formatting and Wikification and use Formatting as a label (adjusting the description as needed), acknowledging the fact that "the {{Wikify}} template is deprecated and has been deemed by the community as too ambiguous; " (source)--DarTar (talk) 20:35, 9 February 2016 (UTC)[reply]
I don't think that this deprecation is a good indicator of the term being problematic. It's just that it was too much of a catch-all. There are lot of types of Wikification (e.g. adding links, formatting headers, etc.) that have more specific cleanup templates. "Formatting" is a statement of fact and belongs in the Object-Action pairs -- not in the intention. Wikify is not ambiguous or an uncommon term. See Wikipedia:Glossary#Wikify, Wikipedia:WikiProject Wikify, etc. If we are discussing intentions then I would rather call this "Wikification" or "Manual of Style". Maybe we could just call it "Wiki styling" if we want to make sure that a non-wikipedian could grok it by name. --EpochFail (talk • contribs) 20:40, 9 February 2016 (UTC)[reply]
if you make the categories too specific there are going to be many edits that are going to need multiple codes, possibly dozens. If you have both general and specific at he same level, and people generally pick just one, people will code the ones with multiple edits s general, and so you will be measuring only those (for example) spelling fixes that occur in isolation. If they code general and specific. If you have general and specific,and people code for both, you're back with the problem of many edits that require multiple codes. For example: [1],where I made minor format adjustments, removed inappropriate content, & moved sections around. Or [2] where another editor adding sections , clarified sone existing one by putting in numerical examples, , and fixed some wording & had just previous done some edits with combinations of large and small changes.
But that said, the overwhelming majority of edits are discrete small changes which can be easily categorized. DGG ( talk ) 21:04, 9 February 2016 (UTC)[reply]
  • Thinking it over, there is no real way of determining this in advance of actual testing at a realistic scale. I think DarTar is correct, at least to the extent we should first test a scheme that is as simple as possible and then use our experience. Viewed this way, it really doesn't matter what we call things initially. The two requirements of a scheme here is the practicality of using it, and the precision of the results obtained. There's no point trying for precision that we cannot easily accomplish, and we won't find out what we can accomplish until we try. DGG ( talk ) 00:13, 10 February 2016 (UTC)[reply]
Agreed! Now we just need to bikeshed about what to call the {MOS changes, Formatting, Wikification, etc.} thing and do it! For the last pilot, we did a 100 edit run (~10 people label ~10 edits each = ~7 minutes per person = 1.1 hours of wiki work). Maybe we can try a 500 edit run this time so that we can get a sense for how this coding scheme works out in practice (~10 people label ~50 edits each = ~35 minutes per person = 5.5 hours of wiki work). This might be the last iteration of the schema before we do a big run, but it's probably worth it to find out. --EpochFail (talk • contribs) 01:09, 10 February 2016 (UTC)[reply]
My preference goes to the least jargony terms that can be explained in plain English: Formatting or Wiki styling both work for me. --DarTar (talk) 04:55, 10 February 2016 (UTC)[reply]
I'm not sure that jargon is what we should avoid and I don't think it is difficult to explain "Wikify" in plain English. Jargon is a good thing when applied within context. It speaks to a specificity that is not available to more common language. It seems that you are using the 3rd definition of wikt:jargon ("Speech or language that is incomprehensible or unintelligible; gibberish.") while I think the first and most common definition is more applicable ("A technical terminology unique to a particular subject."). I suspect that the ambiguous nature of the term "wikify" to you is due to your familiarity with the entity linking problem and one of the early technologies developed for it called Wikify which boldly redefines the term:
Given a text or hypertext document, we define “text wikification” as the task of automatically extracting the most important words and phrases in the document, and identifying for each such keyword the appropriate link to a Wikipedia article.
Compare to Wikipedia:Glossary#Wikify:
To format using Wiki markup (as opposed to plain text or HTML). It commonly refers to adding internal links to material (Wikilinks) but is not limited to just that. To wikify an article could refer to applying any form of wiki-markup, such as standard headings and layout, including the addition of infoboxes and other templates, or bolding/italicizing of text.
I think it is clear from the common use of the term wikify and it's presence in the glossary that it is "A technical terminology unique to a particular subject." For other examples where we draw from Wikipedian jargon, see "Neutral Point of View" and "Link Disambiguation". --EpochFail (talk • contribs) 15:04, 10 February 2016 (UTC)[reply]
@EpochFail: I suggest you go ahead and edit boldly, I still have a preference for the 2 labels I mentioned above but I don't feel strongly about the final choice and this should not be a blocker: there's consensus for merging the two categories, no matter what label we choose. I'll let you merge and I might take a pass and copyedit the descriptions once you've done that--DarTar (talk) 00:04, 12 February 2016 (UTC)[reply]
DarTar,  Done. Please review. --EpochFail (talk • contribs) 17:20, 12 February 2016 (UTC)[reply]
@EpochFail: looks great, I made some minor edits but I think we're ready to roll.--DarTar (talk) 20:27, 12 February 2016 (UTC)[reply]

Wikification description changed

[edit]

After delving into data from the last round of handcoding, where it appears several coders got confused about the exact scope of "Wikification", we decided to change the description of this label in order to:

  1. emphasize that its scope is limited to changes that format content to comply with stylistic guidelines
  2. sharpen the distinction with Copy-Editing
  3. remove examples that were ambiguous

--Dario (WMF) (talk) 04:01, 16 March 2016 (UTC)[reply]

Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia_talk:Labels/Edit_types/Taxonomy&oldid=710301378"