User:Jruderman

Founder of the “New American Synthesis” party in the US.

The party is based on Wikipedia principles and made possible by procedural innovations discovered on Wikipedia.

About me

File:Jesse Ruderman (3 Nov 2023).jpg Jesse in 2023. Photo by D. Hausmann Kogut; used under CC BY-SA.

I'm Jesse Ruderman. I worked for Mozilla a security bug hunter during my life as a computer programmer. After that, I didn't seek employment for more than a few years.

As of 26 Jul 2024, I have a new plan to save democracy from itself. It all started on Wikipedia, because of how Wikipedia defines 'consensus' for internal Wikipedia discussions.

After that, maybe I'll get another job in software security or something.

My website is http://www.squarefree.com/ and I tweet at https://twitter.com/jruderman.

My subject areas

• My professional interest in computer security, including: Fuzz testing, Memory safety, Attack patterns, Vulnerabilities
• The politics of economic policy: YIMBY movement, Gini coefficient
• Applications of genetics, such as exploring ethical boundaries related to Eugenics... and maybe someday doing it right.
• Whatever I'm reading on my phone because someone just brought up the subject at a dinner party.
  • Gotta be polite by having something to contribute to the conversation!

If I were King of Wikipedia

Who died and made you King of the Wiki?
     — Sara Bareilles, probably

Discussion policy

Proposals ordered from least despotic to most despotic

• #TheNewWikiWay, which I discovered during the 2024 CrowdStrike article naming saga, will become policy for complex move discussions.
  • Anyone who is allowed to close (conclude) a move discussion should also be allowed to act as a consensus shepherd instead.
  • Acting as a consensus shepherd – using tools from social choice theory to bring a conversation closer to consensus – should be preferred over closing a discussion as "no consensus".
• Software polling system. Not in the sense of legitimizing voting as an alternative to consensus. Just in the sense of making it easier to record your opinions in a straw poll, when some weirdo decides to use polling as one stage in an overall process that ends in consensus.

Manual of Style

• MOS:BOLDFACE: The common practice of bolding subtopics which are also ''subsets'' of the main topic would be allowed and encouraged.
• MOS:LINKING: include table of ways to make it clear that you're linking to a dictionary definition.
• MOS:DASH: "unspaced em dash" phased out in favor of "spaced en dash".
• MOS:QUOTE: ”Curly quotes” decriminalized.
• MOS would include less instruction creep. Wait, don't remove that rule, that one's important.

IP & Temporary accounts

• Temporary accounts should get silly names such as "avid banana 2024" instead of unmemorable names such as "~2024-12345-67".
• Temporary accounts should have full access to wiki features such as Watchlist
• Temporary accounts should be convertible into real accounts by renaming them
  • Choice to keep the name as-is, drop the year (if open), or enter a new name for the account

Fandom interwiki links

• Articles such as Tatooine would be allowed to have a little box in the top-right like "Wookiepedia has an article on this fictional planet. Wookiepedia is a fan wiki affliated with neither Wikipedia nor Lucasfilm/Disney." This would be general policy for entertainment-related articles, subject to consensus that the wiki is good enough, and subject to consensus on which Terraria wiki is the real one.
• TVTropes too, but only for the narrow category of "articles that are unambiguously about tropes"

Humor as law

• Sockpuppets would be instructed to put on shoes and touch grass.
• Humor would be legal, with the oversight of a Wikipedia:Bad-Joke Identification and Elimination Team.

Truth, Verifiability, and a relentless effort to avoid being misleading in any way

• The core content policy of Verifiability should be joined by the twin new policies of Truth and Not Being Misleading (aka ensuring that most reader will come away believing true things).
• Talk pages should be filled with concerns about how readers might be misled.
  • Talk:YIMBY example with non-central fallacy.
  • Talk:Eugenics example with anchoring bias.
• Articles themselves should just cut out bullshit instead of trying to contextualize it, characterize it as incorrect, or counter it.
  • This is clearly the necessary result of WP:NPOV (as interpreted through WP:FRINGE, WP:DUEWEIGHT) and WP:VERIFIABILITY (as interpreted through WP:NOR).
    • Or is it? Few people agreed with me when I raised this point in a deletion discussion and when I made similar arguments in another deletion discussion (not linked to avoid canvassing an open discussion).

Dear loyal subjects,

Tell me on my talk page which of these I should actually advocate for, maybe.

My approach to collaborative editing

I am one of many autistic Wikipedia editors. Collaborating on Wikipedia is one of my favorite ways of interacting with people, as it plays to my strengths rather than my weaknesses. We're focused on a project rather than socializing in an open-ended way; I can take my time to think about my responses; my tendency to pursue interests deeply prepares me to improve articles in a way that complements others' broader interests.

Use of edit summaries

I'm more careful about including detailed edit summaries and precise references when I'm working in a controversial area or on a page that's already high-quality. Also, a comment regarding when I use edit summaries.

Breaking up large edits

When many are watching a page, I split up my edits into individually describable chunks. My goal is to make it easy for others to verify that each edit summary matches the corresponding changes.

• For potential-controversy reasons:
  • on YIMBY movement (July 2024): Some edits required justification, and some were necessarily interleaved with copyedits. I ended up making about six changes in a row in order to separate substantive shifts from style switches.
  • on IDN homograph attack (August 2024): Uncontroversial edits (one blob) followed by a small edit related to renaming the page.
• For technical reasons:
  • on Template:Infobox Japanese, the diff algorithm was confused about how to display an insertion and number-bumping of subsequent items. (Compare: overall change is confusing, but renumbering followed by insertion is clear.)

Breaking up large changes is a habit I picked up from software development with versioning tools such as git. I think it's appropriate on Wikipedia for the same reason.

Identifying and avoid edit wars

My approach to back-and-forth edits is based more around vibes than about an immutable limit on the number of revert-ish edits. If it seems like we're converging on a mutually agreeable solution, I'm more likely to continue with edits and edit summaries. If it requires more thought and broader compromise, I'm more likely to take it to a talk page. If consensus seems elusive, I'm more likely to back down.

My focus when editing articles

A gnome by default

My first pass reading of an article focuses on clear use of punctuation and sensitive use of language. Later, I may come back to address holistic concerns such as organization and fairness.

A reader-centric approach to neutrality

I see NPOV as implying a requirement that we take into account cognitive biases likely to affect how readers interpret our articles:

• Do not connect a topic to an emotionally salient category earlier than necessary (non-central fallacy) (example: The YIMBY movement and "supply-side economics")
• Avoid introducing incorrect claims, even if described as incorrect (anchoring bias) (example: IQ heritability estimates and economic policy)
• _____ (reification bias) (example: "Dysgenics is...")
• But don't name cognitive biases in article text (e.g. when describing someone's terrible opinion). We don't want visitors to feel like the article is demanding to debate them on its podcast. The language of cognitive bias is for edit summaries and talk pages.

Use of primary sources in addition to secondary sources

Secondary sources are great for establishing notability and proper synthesis, but sometimes a primary source is ideal for establishing that something is actually true.

• Reason magazine says Scott Wiener is part of the YIMBY movement. And so does Scott Wiener.
• This reliable source says Rust's lifetime analysis is a key part of its approach to memory safety. And so does official documentation.

Asking sources to make statements so that encyclopedias can become better

Sometimes it's just a smidge "original research" to make the article easier to understand, and emailing an actual reliable source with a suggestion is the way to go. If this approach catches on, maybe we can call it WP:!!!OR (because WP:NOTOR and WP:NOTSYNTH are taken). Examples:

• YIMBY movement: summary of information about chapters of the national organization?
• Grand Theft Auto (series): fictional-city settings in timeline or table?
• Condorcet cycle: a joke / analogy ?

WP:BACKWARDS

It’s a goal, at least.

My approach on talk pages

Threaded discussion and "refactoring"

I endorse Wikipedia:Thread-mode disclaimer: it is okay for anyone to refactor my comments in a way that preserves my meaning and improves the readability of the overall discussion.

I occasionally edit others' comments to fix small errors that have high impact on readability. I am careful to do this only when it is an unambiguous mistake, when my change is an unambiguous improvement, and when these criteria are easily verifiable by anyone watching the talk page history. If you're happy for me to make slightly bolder improvements to your comments, let me know or link to Wikipedia:Thread-mode disclaimer on your user page.

Subscribing vs Watching

I often subscribe to H2 sections of talk pages rather than watching the entire page. This method means I sometimes miss additions to a conversation that are not written as signed replies, as those are the only ones that trigger notifications.

Linking to specific comments

DYK: clicking a comment's timestamp copies a link directly to the comment? And that following this type of link puts a blue box around the comment?

I didn't know, so I made a terrible CSS hack in my common.css, only recently deleted.

Voting and alternatives

See also my comment "Trying new procedures in Move discussions" on an essay by SMcCandlish

:(

Jesse's device ran into a problem and needs to restart in a loop forever

Survivor of the {{{count}}}-word 2024 CrowdStrike-related article naming saga

In complex situations, I may create procedures for non-threaded forms of discussion, depending on my intuition about what next step will most help move the existing discussion forward.

• House demolition move discussion (still stalled)
  • Big table
• 2024 CrowdStrike incident move discussion (proceeding superbly; winding down)
  • Imposed majority-judgment voting during a mid-discussion poll for the best title
  • Wrote a Recap section to help everyone prepare for the final discussion
  • Transitioned us back from polling to focused, organized, policy-based discussion about the top candidates and individual words
  • Reminded everyone that sometimes a little focused !vote is a good idea.

My focus when editing templates

I am interested in the accessible use of color and images:

• Infobox for US Supreme Court rulings – text–background color contrast (completed)
• Infobox for countries – use of color to indicate whether a stat is good or bad (under discussion edit request submitted)
• Full-URL_wiktionary_link - created with detailed instructions for accessibility

I am also interested in ease of use of templates:

• Added alias {{redirect-for}} (see talk page comment)
• Template_talk:Drv2#"in_article"_instead_of_"article"
• Created the signature separator {{mhair}}

My proudest on-wiki accomplishments

Shepherding discussions:

• 2024 CrowdStrike incident move discussion (ongoing)

Lowering the temperature:

• Stopped an edit war (about whether to include a section) by boldly imposing an compromise based on the magic of hypertext
• Stopped a heated talk-page argument by explaining how following policy can address each side's concerns

Article content:

• Wrote a good portion of the Fuzz testing article.
• Contributed to lists in articles: Types of software vulnerabilities and Types of memory safety errors

My customizations to the editing process

• Settings:
  • Links to disambiguation pages – orange
• common.css:
  • Discussion anchors – makes it easier to link to a specific comment in a threaded discussion
  • Watch page – highlight page names
  • Watch page – hide thank/rollback buttons
• Experimenting with:
  • Definition list styling – so I can notice if ; is misused for pseudo-headings or : is misused for indentation (outside of talk pages)
  • Links through main-space redirects – green?
  • Links to policies, guidelines, and essays – various shades of green?

Templates created

• Recuse from closing a discussion – shortcut {{recuse}}
• mhair – shortcut to place a nice long dash before a signature
• CrowdStruck 200px
• CrowdStruck thanks
• Full-URL wiktionary link (logo acts as a hint that a link goes to a dictionary definition)

Tweets inspired by my Wikipedia experience

Some of these are threads. You may need to be logged into Twitter to see the whole thread.

• hatnotes
• sans-serif
• "dysgenics"
• "eugenics"
• Stay tuned if you know what I'm going to post about next