User:SoledadKabocha

I am aware that in the interest of humility, many users choose not to write content for their user page, perhaps instead redirecting it to their user talk page. Unfortunately, that ship has sailed...

Conventions and etiquette

I will reply to a discussion where it was started. This means that I do not prefer {{talkback}}.

Use {{reply to}}/{{ping}} only when the discussion has a third (or more) participant besides you and me.

If you wish to revert my edit, please do not remove the default "Undid revision ###..." text entirely from the edit summary. This is to ensure that the notification system works correctly.

Speaking of notifications, to avoid creating unnecessary noise in the "mention" subtype:
Please avoid wikilinking my username in an existing discussion (i.e. one not newly started by you) within the talk namespaces.
(Copying and pasting discussion from another venue is an exception; I do not expect my username to be unlinked.)
In particular, do not use {{reply to}} when making the first and only reply to a discussion started by me.

Generally, I will voluntarily follow "0.5RR": I will not revert more than once before discussing, nor will I re-revert any good-faith reversion without first discussing it. I use this term because "one RR" is one reversion cycle (revert and re-revert), which I avoid.

Deprecated? I use {{tlx}} even when {{tl}} would suffice because I've been told that the <code> formatting is more semantically correct than plain type.

In regard to discussing the printability of redirects, I agree with the use of "printability" and "unprintability" as the noun forms, but I will likely continue to use "printworthy" and "unprintworthy" as the adjective forms, if only because "printable" implies "printable character" and "unprintable" implies "profane."

Many users routinely give "re" as an edit summary in discussion replies. I consider this just as bad as no summary and make every effort to write something descriptive even if it sounds strained.

Notes on categorizing redirects

When I mention in an edit summary that "R from related word has been deprecated...," I am referring mainly to the use of {{category diffuse}} on the category page Redirects from related words. I am aware that the R from related word template does not use {{tdeprecated}} and is unlikely ever to do so.

When are edits to redirects minor?

I used to flag all edits that solely affected the categorization of a redirect as minor. (On the other hand, I have always treated any change to the target of a redirect as major.) I have since revised my personal guideline to include the following criteria for redirects within the main namespace:

1. Any RCAT change that alters the overall printability state of a redirect is major, except to fix a redirect that is categorized as both printworthy and unprintworthy (see #5).
2. The addition of RCATs related to attribution is major; this includes {{R from merge}}, {{R from duplicated article}}, {{R with history}}, and {{R with old history}}
   ...except that {{R from move}} is still minor, because (1) it describes an action that is logged anyway, and (2) the MediaWiki software is configured to add it automatically to new redirects created from moves; adding it to old moved redirects is uncontroversial. TODO: Deprecate this rule? I haven't been following it lately...
3. The removal of an existing RCAT, whether or not it is replaced with another, is major...
   ...except for trivial maintenance such as the removal of templates that are nonexistent (redlinked) or that were added in obvious bad faith. This serves as a courtesy to other editors. Note that reversions not of vandalism, whether self-reversions or not, do not automatically fall under the exception.
4. Any edit that affects (adds, removes, or replaces) three or more RCATs is major.
   Rationale: Edits that affect two RCATs are common, but those that affect three or more RCATs are rare. TODO: Exclude explicit {{R unprintworthy}} and {{R printworthy}} from the count? I haven't yet encountered a case where this matters, though.
5. I consider the following trivial maintenance and therefore inherently minor. That is, they are minor when done by themselves, and they do not affect the minor-edit status of other changes (example):
   • Adding {{redirect category shell}} around multiple Rcats – this item originally described the deprecation of {{this is a redirect}}, which has been completed by bots
   • Bypassing of RCAT-template redirects; per WP:NOTBROKEN, I will avoid doing this by itself, and note that this should not be done at all for the redirected templates mentioned in the text of {{R from alternative spelling}}
   • Addition of the "of" parameter to {{R from misspelling}}, in simple uncontroversial cases where the correct value is obvious
     (In the spirit of #3 above, modifying or removing the parameter if it is already present does not count as minor unless I am doing so to fix obvious typos or vandalism. For a case that is not "simple," see Facist/Facism; note that my edits to said redirects may no longer represent my current guideline.)
   • Correction of mistakes that categorize a redirect as both printworthy and unprintworthy, for example changing {{R from plural}}{{R printworthy}} to {{R from plural|printworthy}}

As of 23:28, 3 February 2017 (UTC), I will no longer flag any edits as minor for redirects from or to any non-article namespace; this includes, but is not limited to, cross-namespace redirects. The rare edits that hit only #5 above are not an exception to this, as the criterion applies only to mainspace.

Unnumbered because it is temporary and will be reviewed later: As of 18:04, 15 December 2020 (UTC), I will treat addition of {{R avoided double redirect}} as major. (This could be considered attribution-related and thus combined with #2.)

If the edit only affects categorization and does not meet any of the above criteria for a major edit, it is minor.

Mistakes to fix

TODO: Split to /Rcat mistakes

Semantic correctness

It is important to ensure that all Rcats are semantically meaningful for the exact title of the redirect. In particular:

• I may have misused {{R from former name}} together with rcats for names of different length ({{R from long name}}, {{R from short name}}, {{R from initialism}}, {{R to initialism}} etc.); discussion has since determined that such categories require the long and short forms of the name to be in simultaneous official use.
• Per this discussion: Except attribution-related Rcats such as {{R from move}} and {{R from merge}}, printability-neutral Rcats such as {{R to initialism}} should not be used with highly-unprintworthy Rcats such as {{R from misspelling}}. A highly-unprintworthy Rcat is any whose template reads, "Pages that use this link should be updated to link directly to the target..." (emphasis mine).
• Every mainspace-to-mainspace redirect should have a printability defined, but in practice I don't manage to achieve this. Often this is out of laziness, but sometimes it is genuinely difficult to judge a particular redirect correctly.
• I have often failed to use {{R avoided double redirect}} despite it being a growing part of current practice.

Legacy practices

• I may have misused {{r from modification}} for grammatical modifications where a more specific template is available, such as the "r from (part of speech)" templates. I'm not sure how big a deal this is, but I'll try to fix it nevertheless.
• I may have used {{r from long name}} in isolation when a more specific r to... (acronym or initialism) template is available.
• The definition of {{R from unnecessary disambiguation}} was recently clarified to apply also to natural disambiguations; I have now-incorrectly categorized some of those as "other" or "incorrect" disambiguations.
• As mentioned above, {{R from plural}}{{R printworthy}} should be {{R from plural|printworthy}}. I caught this mistake once; did I do this at any other times in the past?
• I have often failed to follow the practice of explicitly marking printability even when set by other Rcats, just because I was unaware of it or didn't agree with it.
  Note that as of 01:25, 16 September 2020 (UTC), I will no longer make any edits solely to enforce this, that is, adding only R (un)printworthy to redirects already categorized as such by other Rcats. Adding R (un)printworthy in the same edit as other Rcats that affect printability is still encouraged.

Not Rcat-related (FIXME!)

I've often failed to mark simple additions of wikilinks as minor; the problem is that I've confused wikilinks with "visible tags or other templates."

Article drafts to work on

Uncontroversial/high priority

None currently

Dubious/low priority

I have no specific timeline for this work due to things going on in my life. If you really want me to work on one of these ASAP, I encourage you to talk.

• /List of Electronic Frontier Foundation software – or possibly "List of Electronic Frontier Foundation and Tor Project software"? – possible merge target for Switzerland (software), HTTPS Everywhere, and Privacy Badger if their notability is ever questioned in the future
• /List of video games vulnerable to arbitrary code execution – might not be a good topic even if we require citations for every entry; organize based on "exploitable from normal user input" vs. "requires a save file to be modified/corrupted outside the console"

Arcade system boards by company

Compare the existing article List of Sega arcade system boards.

• /List of Atari arcade system boards – expand Atari System
• /List of Namco arcade system boards – merge those found in Special:PrefixIndex/Namco
• /List of Taito arcade system boards – merge those found in Special:PrefixIndex/Taito

Notes to self/general wall of shame

Three observations

1. WP:BURDEN says "adds or restores," not "adds or removes" – with good reason.
   It is generally improper to revert, without first discussing, any "out-of-process" removal of content with notability/sourcing concerns. In particular, this means discussion in order to organize a search for references. (Example)
2. WP:PRESERVE is not a suicide pact.
   Remember that it says "Try to fix problems"; that means that you must actually make a good-faith effort to improve an article and that you will not necessarily succeed in bringing it up to standard. It is not a carte blanche justification for inclusionism, and nor is WP:ATD. Even though it should be common courtesy to suggest alternative outlets, it is futile to require their use. Don't be afraid to remove poorly-sourced and/or non-notable content, even an entire article, no matter how much you may be interested in the topic. (Related: From WP:CONSPLIT, "it may be more appropriate to simply remove the material from Wikipedia than to create a new article.")
3. "Consensus can change" does not mean "consensus must change." (Note: Don't create a standalone essay for this one item; consider expanding WP:Consensus doesn't have to change instead.)
   1. It does not mean you can change any consensus you want.
      It is redundant to say "established consensus," because a consensus is an agreement among multiple people and must be inherently hard to disestablish. Extraordinary claims require extraordinary evidence, especially when they are about policies and guidelines.
   2. Consensus is not temporary.
      Don't discount an old consensus just because of the time that has elapsed.

Count of mistakes caught by bots

• BracketBot: 1(and no more)
• DPL bot: 0 (let's keep it that way)

I am a native speaker of American English, but that doesn't make me 100% reliable at subtleties like this, especially when there's so much else going on in my mind. (Note to self: In the future, try to reword the sentence to avoid tricky cases.)

Subsections

• /articles to merge
• /dubious feature requests
• /essays
• /redirects to create
• /scripts
• Automated list (t)