discursive strategies in style guide negotiations on github

introduction

incipit

• the tale of the real programmer who could speak with the machine
• • the tension between artistic skill and group coordination
• • the answer is a style guide to make everyone agree, but even that proves to be complicated

definition of style

• simmel and artistic style
• • talks about how style has an inherent tension between individual and group
• • our focus on style as a group action (both rancière & standardjs)

the need for style in programming

• development of programming as a profession in the 1960s (djikstra)
• • moving from an obfuscated practice (women computers)
• • to an esoteric practice (the art of programming)
• • to a large group practice (GOTO, clean code, mythical man-month)
• the readerly and the writerly in barthes
• • the necessity to be able to write when you read (the assumption that, when you read, you will write)
• • opportunity to highlight a separation between barthes’ conception of style (individual, meaningful, etc.) as opposed to the “langue”: common, archaic
• finally, programming is hard as fuck
• • the need to understand mental structures is complicated enough that we invented high enough languages to deal with those problems

the style guide as an object

• description of the style guide
• • reference document about both syntax, with references to a need for readability (skimming a text) and clarity (deep-diving a text)
• goody and literary organization of social life
• • develop on how the style guide embodies administrative work

the ecosystem of programming

• github
• linters
• • linters as objets intermediaires (multiple facets)
• • the connection with actor network theory

question: what are some of the discursive strategies in place regarding style guide adoption and modification? how are these connected to, and affected by github?

hypothesis: the socio-technological milieu in which these discussions happen affects the argumentation

research methods

• qualitative
• discourse analysis
• franekel

locus of research

• on github
• • explain the difference between the three repo chosen
• • • same language
• • • different approaches (airbnb: internal dev + explanations, standard: external dev + multiple necessities, prettier: only style, uncertain document)
• outside github (additional texts)

analytical categories

• emotional justification
• rational justification

• technical justification

• socio: founding texts
• socio: community/project
• technical: the functional

findings

• objects are multifaceted and entangled/entangling
• personal preferences (means) can always be subsumed by calls to “efficiency” and “precedence” (reference to a canonical document)
• calls to “fork” are always the conclusion of an argument
• github issues can have multiple functions (pedagogical, antagonistic, reporting)

conclusion

• sum up

in the end it’s affected by github’s:

• forum mechanism
• cross-reference across repos
• ability to fork