Pierre Depaz - email@example.com
Written and published in 1983 on a Usenet board, The story of Mel, the Real Programmer1 recounts^[this is an inline footnote] the tale of Mel Kaye, an individual who wrote software on the 1959 ACT-1 compiler and has become a recurring reference in programmer’s lore2. The moral of the story focuses on Kaye’s ability to write both excellently efficient and completely inscrutable code. This obfuscating aspect of a code that only its writer can read, while being considered in this context a laudable feature of model programming work and informing ideals of programmers, slowly began to phase out in the 1970s. With the growth of the commercial software market3, more and more private companies started to constitute what is today a large part of the technology industry, composed of teams of multiple programmers working on the same codebase on the long-term. This evolution, from the individual programmer implementing ad hoc and personal solutions to a group of programmers coordinating across time to build and maintain large, distributed pieces of software, brought the necessity to harmonize and standardize how code is written. In response, style guides started to be published to normalize the visual aspect of source code, and became a recurring topic in both the software development and computer science research4; particularly, debates about programming style implementations and best practices have remained significant, if under-examined, parts of a given programmer’s practice in a commercial context.
In the first part, I will address the origin of style in programming and, consequently, the need for style guides in contemporary, commercial programming practices, inscribing it further into both the sociology of style and the sociology of organizations. In particular, I will highlight continuities and breaks between style guides for human languages and style guides for programming languages, specificaly in terms of objective efficiency and subjective perception. Building on this dichotomy, the second part of this article highlights the specific technical intermediary objects9 involved in those discussions and implementations, which exist in this field at both a macro- and micro-level. Both GitHub and linters are significant components of the creation and implementation of style guides and will thus occupy a central role in this analysis. After developing on the research methods used in this study, which are centered qualitative discourse analysis of issues and pull requests, I will develop on the findings of this research, summing up discursive and structural differences between the three targeted repositories. I will conclude by focusing on the place of tools, read-only documents and read-write documents, as well as invisible communities, in the development of style guides and how these can inform our understanding of daily programming practices.
The problem of style is a problem which echoes Simmel’s statement regarding the observation that “the practical existence of humanity is absorbed in the struggle between individuality and generality”10. Simmel’s investigation of the topic, which will serve as the foundation for our definition of style, focuses on the dichotomy between works of fine art and mass-produced works of applied arts. Indeed, Simmel draws a distinction between the former, as indiosyncratic objects displaying the subjectivity of its maker, and the latter, as industrially produced and replicated, in which the copy cannot be told apart from the original. The work of fine art, according to him, is “a world unto itself, is its own end, symbolizing by its very frame that it refuses any participation in the movements of a practical life beyond itself”, while the work of applied arts only exists beyond this individuality, first and foremost as a practical object. As these two kinds of work exist at the opposite extremes of a single continuum, we can insert a third approach: that of the crafted object. The work of craftsmanship exists in-between, as a repeated display of its maker’s subjectivity, destined for active use rather than passive contemplation11. So while style can be seen as a general principle which either mixes with, replaces or displaces individuality, style in programming doesn’t stand neatly at either extreme, and needs to be problematized further.
Source code, understod as the product resulting from programming work, finds some of its roots in craftmanship, as a practice both analyzed by scholars12 and claimed by practicioners13. Programming work has developed since the 1950s from an invisible labour to a fully organized and codified practice, through individual, glorified work. While computers were originally referencing female clerks implementing male mathematicians’ algorithms on mainframe computers14, the development of programming as a recognized practice brought about with it the figure of the individual (male) programmer, equally obsessed and talented15, echoing in some ways the portraits of the genius artist1617. This individual, free-form implementation of specific computational problems came to an end with the rise of commercial software, and led to a re-examination of the practices and processes of software developers. This was led in part by the work of Edsger Dijkstra whom, in his 1972 publication of Notes On Structured Programming16, set forward clear practices for writing source code which would be meant to achieve two aims: be readable by someone else than the original author, as well as being more reliable and error-free18.
The emergence of style in computer programming is therefore concomitant of the development of the software industry, starting in the 1970s. A self-proclaimed highly complex undertaking19, the understanding of source code by someone who hasn’t written it (or, being the writer, hasn’t read it in a while) quickly proved itself to be particularly difficult; as a response, corporate literature arose in order to serve as a reference for best practices20. Style guides, in the context of programming, are textual documents whose rationale involve both social and technical components. On the social side, they are only truly useful if they are inconditionally adopted by all members working on a particular code-base, since “all code in any code-base should look like a single person typed it, no matter how many people contributed.”21; in the strict sense, guidelines are therefore reference documents which should provide an answer to the question of what is the preferred way of writing a particular programming statement (e.g.
snake_case). Beyond aesthetic preferences aimed at optimizing the clarity of a given source code22, style guides also include a technical component which aims at reducing programming errors by catching erroneous patterns in a given codebase (e.g. variable declaration before intialization, loose reference to the function-calling context). This technical component, because it can be judged by an objective standard (i.e. the amount of breaking errors in a program), is seldom the reason for internal disagreements within teams. In contrast, the aesthetic component, due to this lack of subjective criteria, opens itself up to discussion. It is both of these components which style guides aim at resolving.
This phenomenon of explicitly written rules, dependent no longer on their writer, but rather on the organization to which the writer belongs, presents similar patterns as those highlighted in the formalization of knowledge as it happened during the transition of societies from oral communication (and their constituting organizations) to written communication23. For instance, the written codification of hitherto implicit, idiosyncratic rulesets, has had the result of further preventing modification of said rules, and elevating them from a “personal” reach to a “universal” one; and these are patterns that re-emerge in the use of styleguides. However, the technical context for those studies of the impact of literacy is one in which the written word, once put down, is significantly harder to modify than both its spoken counterpart and its digital counterpart.
The digital word, the word stored on and communicated via computers, presents two important differences. First, it can be as easily modified as it can be retrieved. Since one of the basic operations of the computing machine is the act of copy and the act of retrieval, it is important here to remember that anything that can be said on a digital medium always holds within itself the possibility of duplication, modification and, therefore, variation24, illustrated on the most obvious-level by the ubiquity of “copy and paste” actions offered as a default by any word processor application on a modern computer. Second, source code written in programming languages is executable. This means that, beyond the linguistic act of writing a statement, the result of this writing act can be automatically executed and enforced, without stating the need for personal or social performance as a requirement. So while written code still exists within “chains of acts of writing”25, once its validity has been confirmed and merged into active code bases, its enforcement is significantly easier than that of guides and protocols written in human languages26.
Along with the low barrier to reproducibility and enforceability of code explicited above, another difference between organizations centered primarily on code and software and organizations in which code only constitutes a technical background is the porosity of the distinction between public and private. Particularly, when organizations maintain, or depend on, open-source software, the delimitation of which individual contributes to the organization’s product becomes more fluid and temporary than in more traditional organizations27. At its most radical form, it is entirely non-hierarchical and horizontal28, a structure in which anyone can comment on the product and suggest modifications, even though actual contribution remains subject to additional social and economic constraints29. This configuration directly affects the scope of a style guide. If anyone can potentially contribute to any code base within a given language, then the potential scope for any style guide is that of universal adoption. This relatively loose set of mutually-beneficial work relations (between private companies, open-source organizations and individual contributors) constitutes the background of our research field and is accentuated by the specificity of the GitHub platform.
As all platforms, GitHub conects multiple actors and provides the backdrop for economic, social and cultural practices30. Economically, GitHub provides a way to store, retrieve and modify text files (usually source code) for distributed teams of contributors, grouped into projects (called repositories), themselves administrated by either personal or organizational accounts. Any public repository is accessible to anyone, and these projects can then be built to add to the value of a given commercial product (e.g. Apache’s
create-react-app). Socially, GitHub requires user registration to contribute to any of those repositories, and maintains a transparency policy which makes available all of a given users contributions on any given public repository. These contributions overwhelmingly take the form of commits (direct modification of text files), pull requests (requests to a given organization to integrate suggested changes to a text file), and issue creation and comment (asking or answering a question on a given project repository). Culturally, user interactions on GitHub depend on agreed-upon practices and discourses, specifically when a user raises an issue, responds to it, or concludes (closes) it31.
prettier/prettier (37.4k stars, 2.5k forks) and
README.md, the first page displayed on any GitHub repository, as well as configuration files for linters. The
standard/standard repository is a non-profit open-source organization aiming at providing a non-modifiable, non-extensible way to programmatically enforce both stylistic choices and technical error-checking through the use of the
standard software, a command-line utility which aims at automatically enforcing the style described on an additional
RULES.md document37. Finally the
prettier/prettier repository limits itself to the strict formatting of source code, following the rules laid out on an external website38 and providing, similarly to
standard/standard, a command-line utility to automatically enforce those changes39. GitHub is therefore a combination of read-write texts and read-only texts. The read-write texts consisting of the main text files of the repository, while the read-write texts are composed of all the discussions and suggestions taking place in the issues and pull requests sections. Drawing from literary theory40, this distinction allows us to identify the more authoritative text and the more negotiable ones.
This study focuses on the issues sections of each of these repositories. Traditionally used to keep track of bugs and technical enhancements for project maintainers41 and have a dedicated section on each repository. An issue can be created by anyone with a GitHub user account, can be commented on by anyone with a user account, but can only be closed (or “resolved”, in GitHub’s terminology) by the original creator, or by project maintainers. Additional features is that they can reference other issues across repositories, as well as internal and external code requests, essentially creating a web of inter-textuality, and displaying the complexity and inter-dependency of software packages. While originally designed as a bug-tracker, research has shown that they are now the locus of more complext discussion, involving affective rhetoric and over-arching design inquiries, well beyond specific technical fixes4243.
eslint, with over 13 million weekly downloads45. While not proposing entirely new linters, our examined repositories focus on maintaining configuration files for
eslint which implement their own human-readable styleguides. As a tool in a programmer’s workflow, these linters with their associated configuration files are what Latour and Woolgar have called intermediary objects46, objects which contribute essentially to labour and knowledge-creation. Previous research in the sociology of work focused on how these intermediary objects affect the work processes (both conception, discussion and realization)47, particularly in establishing a framework within which work can take place48; coupled with the automated normativity of code4950, these linters represent a significant part of the life and impact of a style guide.
After having provided the context in which this study takes place, we turn to our methodological approach. The methodology employed here to analyze (1) how different actors negotiate the adoption and negotiation of both subjective and both objective stylistic norms, and (2) the influence of the technical environment in which those discussions take place, is based on the discourse analysis of individual issues and pull requests in each examined repository. This approach will focus mainly on the most debated (i.e. those with the most comments) issues, highlighting the discursive strategies and patterns of the participants; since most of the least-commented issues are overwhelmingly related to technical issues and bugs which, by implying a single fix, stand outside of the field of argumentation. Specifically, this methodology aims at linking the meanings of the corpus not just to existing social realities51, and to different kinds of communicative competences but to technical realities as well. Habermas provides a useful typology of communicative competence, composed of “a statement of fact, an expression of feeling, or a command”52; and this typology will serve not as a normative framework, but rather as a starting point for approaching the positions, assumptions and aims of contributors in the discussion. Regarding the restriction of the analysis to the exclusive locus of issues and pull requests, as it has been mentionned above, GitHub is composed of an intricate web of texts which cross-reference each other, and therefore renders any clear distinction blurry. As such, we will consider that a read-only document (such as
README.md) will be relevant to our analysis insofar as it addresses a specific user, with a specific voice: if this linguistic interaction doesn’t imply discussion, it certainly implies discourse.
Several studies have previously looked into the discourses on open-source communities53, mostly through the use of large-scale computational techniques5455. The proposed approach intends to examine more specifically the nuances and implicit assumptions within the arguments deployed by the user, working under the hypothesis that, while broad strategies have been identified for issue resolution56, a more detailed approach in the specific field of styleguide adoption might provide insights in the daily practices of programmers, and to what extent they implement, re-appropriate, or hijack (détournent) the broad strategies of technical resolution assumed by the GitHub platform57.
As pointed out by mylestan, the
Hi! First off, thanks for this package. Also, I’ll preface this with: I’m not 100% sure I’m using the react/whitespace option correctly, so this is more of a question than a bug report.
With a low ratio of open-to-closed issues, the
eslint59, individual projects60 or the guide itself61, even though all issues that are labeled as “bugs” represent less than 1% of the total issues opened. In this case, bugs are understood as inconsistencies between the eslint output and
Indeed, the unique aspect of
Additionally, a particular aspect of
README.md77. By coupling exhaustivity with justification, the main task remaining for the maintainers of the project is to continue the explanation of why things are the way they are78. The case of
prefer-default-exports highlights the pattern of a maintainer repeating the same justification for recurring questions798081. What happens on the repository is the development of a pedagogical discussion in which the “bugs” opened are presented as misunderstandings from the commenter’s point of view, asking the maintainers, not to justify their style choices, but rather to explain how one can write code that would better match the guidelines explained82. If that explanation fails, as in the
prefer-default-export examples above, another strand of conversation is engaged in by one of the core maintainers, user
ljharb not only acts as a community manager rather than a project maintainer per se, but also eschews any discussions based on subjective preferences by providing a technical solution to any question asked, therefore showing that the
What we’ve seen in
airbnb/airbnb provides a main
README.md, with all the style rules immediately available at first glance, along with a
eslintrc.json configuration file as the result of the closed-source work of a private company,
standard/standard puts forth the
standard binary, an immediate, “out-of-the-box” solution which applies the project’s rules to any file where the program is executed85. The overall approach comes out of a more traditional open-source pattern, initiatet and spearheaded by a single individual,
feross, which then turned into a proper organization once enough community traction had been garnered8687.
The self-stated goal of
standard/standard of “no configuration”8889 has led its maintainers (mainly
feross, along with rotating members such as
rstacruz) to inflect their discourse under the influence of technical efficiency, rather than rule justification as
feross as well as discussed by the community—groups of users, members and contributors—for each release of the package. By leaving open the possibility of modifying their style rules, and subsequently making them immediately enforceable by their
standard binary, the discursive focus isn’t so the number of discussions of so-called “religious” issues, known for the amount of devotion and heat that they attract (e.g.
indentation93), but rather on technical implementation, alternative possibilities and community support.
The first category of arguments laid out in the
standard/standard repository is related to the actual, technical feasibility of the arbitrary94, but not non-sensical, rules laid out in the
README.md. The status of
feross as “benevolent dictator”959697 nullifies most of the arguments (e.g. “All very subjective though. I think @feross will just have to pick something :)”98), the remaining of which can sometimes be rationally discussed99100. Given this status of most rules being somewhat indiscutable, upon what does the agreement of
standard/standard rules rely? The status of the project as a convenient wrapper (i.e. a seamless intermediary object in a developer’s workflow) around
eslint poses that core technology as one of the final assessments of the validity of a given argument (e.g. “Probably better off making your case at eslint first, then coming back here”101). While this effectively avoids bikeshedding102 in cases where the ultimate goal is to settle with one choice rather than debating multiple of them, this technological dependency also prevents some desired changes103.
If the stylistic preference of a commenter still weighs more than the ease-of-use of the
standard/standard package, then the strategy of the maintainers is to redirect them towards another part of the ecosystem, be it the direct configuration file which implements all of the style rules104, or the adoption of other packages maintained by the
standard organization105106107108. Different from the dismissive tone of the
feross109). Indeed, the word community is used most often on
standard/standard by the maintainers (given an equivalent number of issues on each, respectively 34110 vs. 39111). This emphasis on community-building as a part of the overall strategy of
standard/standard also affects their discursive strategy.
With a set of rules overwhelmingly decided upon by
feross, some rational argumentations for the modification of these rules, the reliance on
eslint as a ground for whether or not a rule can be applied, and the redirection of unsatisfied, or unconvinced community members towards other packages of the
standard ecosystem, such as
standard/doublestandard for “religious” issues, the last remaining argument deployed for the adoption or rejection of style rules is the extent to which the community is using the existing rules.
On the one hand, this project has garnered visibilty and is currently deeply embedded in an institutional network of projects using the
In practice, the biggest role that the community has in the negotiation of style guides is in whether or not any change in the guide would be a breaking change, and for how many projects using
standard/standard. Used by project maintainers (“This is one of those decisions that we can’t revisit. Nearly every repo that uses standard would break, and that’s not acceptable – even with major version bump.”115, “Although personally I agree with the fundamental reasons that you argue for this. As it stands, this would be so much of a breaking change, it will never be accepted.”116). The closing argument is therefore the number of existing projects which would have to refactor their code in order to comply with the new rule, and is often the last comment to take place on an issue before that issue is closed117118[^95], acting as a unilateral reason.
The discursive strategies that the commenters and maintainers deploy in
standard/standard then revolve around issues of convenience, which have enabled what could be called a certain form of social path-dependency119, in a productive sense. The figure and work of
feross, both agreeable and engaging in his exchanges and unilateral in his decisions, include in their discourse references to technical limitations in order to bypass subjective issues. Indeed, while the affordances of
eslint are inherently digital, the adherence of silent majority of
standard/standard users is represented in a quantified manner, through unit tests resulting the a percentage of organizations and packages failing or succeeding said tests; and such an approach seems to manifest itself as the reification of community choices in order to increase its effective discursive power.
prettier/prettier project is both the most recent and the most popular (based on both stars and weekly downloads120), and offers a third approach in our analysis. Developped in 2017 by Facebook employees, which is one of the world’s largest and most profitable companies, as well as the maintainer of the
react project, the most popular front-end development framework by the end of 2019121. Beyond this institutional backing and internal success122,
prettier/prettier presents two specificities which differentiate from
standard/standard. First, it doesn’t offer a clear and accessible style guide itself, and its
README.md only contains one example to show the kind of work
prettier/prettier does. Second, what it does is essentially different than the two previous examples looked, since it analyzes the source code, parses it and its inconsistencies and entirely reformats it according to internal rules—neither
Along with the absence of a clear styleguide announcing, if not explaining, the individual style decisions, the maintainers of the project (e.g.
vjeux, founders of the project while Facebook employees) tend to engage in conversations about the possibility to change existing styling rules124125126. This willingness to change the behavior of their tool, along with its automation power and the founders institutional capital might explain the fact that the
prettier/prettier repository has about four times more issues in total than the two other repositories examined, with more thoughtful, thorough and rational explanations127128, including detailed description of desired behaviour129. In particular,
prettier/prettier distinguishes itself by allowing contributors to open up discussions and negotiate changes not through pure discursive argumentation, but rather by offering practical and thorough implementations of an alternative130, including atlernatives which concern “religious” issues131—in effect, long and elaborate argumentation always require code examples132133. The process seems to be as follows:
prettier/prettier formats a given code, the developer who might not agree with such a formatting result opens up an issue, argues for her opinion through the presentation of practical use-cases and actionable pull-requests and, depending on the technical soundess of the solution and the size of the community already using the package, might get their change accepted. Finally, while the thoroughness and politeness of most replies on this repository point towards a healthy community, it should be noted that the verbosity of some of the contributions are considered intimidating for comments who consider they English level sub-par(e.g. “I didn’t read the whole conversation above because you guys really know how to speak English well slightly_smiling_face Makes me envy a bit”134).
Without a reference document, and with the recurring statement that “readability” and “preference” are subjective arguments,
prettier/prettier relies on technical arguments to solve debates, sometimes even before they happen. Before they even happen, because the seamlessness of the integration, as both a visible and invisible mediation, can eschew those debates altogether (“Hi @jlongster, just would like to chime in and let you know that your project has hit the jackpot and solved something that even (the self-proclaimed) Standard and Semi-Standard couldn’t solve for me […] Easy team-wide style enforcement that’s based on an unbiased 3rd party algorithm to produce a one and only definitive way to indent absolutely each line of code”135). This immediacy of programmatic action, and its adoption in return, is reminiscent of the power of interfaces in their ambiguity, in which a self-implementing tool acts as its own rationale136.
However, most of the official discourse of
prettier/prettier (through its website and through oft-referenced conference talks) presents the project not as a style-guide per se, but as an AST-parser and printer. These technical definitions steer the debate towards technical argumentation, rather than adoption by the community (such as standard), or explanation of practical raitonale (such as airbnb); explicitly mentioning AST representation often becomes the grounds for the final stylistic decision (“It will be interesting to figure this out because the way it formats it now is because of how the AST is structured, which is based on operator precedence”137138139140), and sometimes even used as counter-examples141.
prettier/prettier’s argument is that it is both opionated and efficient, which has led to the early development of a “no-options” philosophy142, which has moved from a read-write text, discussed by both maintainers and commenters, to a read-only text, as a canonical text on the official website143, which is then used subsequently as an argument to respond negatively to requests for personal additions144145146, combined with a request of responding through programming languages, rather than human languages147. This particular phenomenon echoes practices found in the
A final feature of the
prettier/prettier discussions stems from both their exhaustiveness, the popularity of the project and the maintainers’ decision to no longer accept options149. This results in several seemingly intractable discussions with over 100 comments, while the majority of other issues have less than 10 comments each)150151152153. These issues bring up the original tension of a styleguide, in which each writer has an opinion154 on what is the best way to solve a given dilemma155, either as emotional, subjective statements156 (“This issue is ridiculous. Just fix that”157), or along with examples158 and offers of pull requests. The pattern we see here is that, due to the popularity of the project, first-time users weigh in on complicated debates, engage in the conversation with other commenters for a couple of replies, and then drop out of the discussion altogether). Coupled with the original intent of the maintainers to integrate community-argued changes, these issues remain open for all to chime in (most of them being over 3 years old).
On the one hand, these discursive strategies seems to parallel the pattern of the dreaded bikeshedding159, in which anyone can chime in including linguistic patterns such as “just my two cents”, “IMHO” (“in my humble opinion”), “just gonna weigh in here”, apparently. As such, they don’t seem to appear very productive at first glance due to repeated arguments160161 and affect the maintainer’s ability to discuss (“The Prettier issue tracker naturally attracts and concentrates code style discussions. They’ve been moved from basically everywhere to here. I think this is a big factor to the maintainer burnout I’ve seen lately.”162).
On the other hand, however, the overall quality of arguments presented (combining use cases, opinions and responses to previous proposals) has led to a switch in the discursive strategy in which the discussion is either summed up by the maintainers163164165 in order to provide moderation to the debate or to be pursued privately by the maintainers166167. The result is that, emerging from community-created discursive noise inherent to any popular open-source projects, the
prettier/prettier team engages less in terms of justifying the existing style, but in gauging how feasible an alternative is, once this discursive noise reaches a particular threshold, acting as a filter to turn quantitative input into qualitative decision making, the existence of the issue itself acting as an argument.
Style guides existing on GitHub have to tend to the specific issue of convincing individual users with strong subjective preference of adopting their recommendations in the midst of a technical environment which favors copying and customization. Starting from an approach of arguments based on the framework of communicative competence, we’ve highlighted that, beyond emotional and subjective statements (sometimes disguised as rational ones) as well as the social justification of institutional origin or belonging, rational statements and commands are being affected, to some extent, by the techincal milieu in which programmers write, read and work.
Particularly, we can see that there are multiple strategies which involve closely either source code, or compiled code. Source code acts as a prime argument when human languages fail to communicate the objectivity of their statement, and is often required by all parties of a discussion to base statements on what is considered a fact. Still, those comments are often overlooked: the requirement of readability, crucial to a decision in style guides, re-appears in all its subjectivity when it comes to reading the source code example provided, pitting the argument in multi-sided subjective perspectives. In
If source code seems to be a novel type of argument, adding to the traditional realm of human rhetoric, and yet remains trapped in subjective appreciation, compiled code can act as its own argument. In both
prettier/prettier, both of the projects rely on the fact that their style guides work, that they are efficient in what they do, and any change must first and foremost comply with the feasibiliy of the argument, no matter how sound the conceptual proposal is; as we’ve seen,
prettier/prettier can replace a didactic guide by an efficient tool, while
eslint configuration file, leading us to the consideration that code as actionable words, a silent argument of sorts, is perhaps the most efficient in the adoption of a project.
In terms of GitHub as a platform, the structure within which these projects take place, we’ve observed a multiplicity of approaches, preventing a unilateral interpretation of how technical environments can entirely shape the nature of a discussion. Between
standard/standard’s desire to fix practical implementations of the tool they provide, and
prettier/prettier’s use of a more classical open-source discussion, GitHub’s platform seems to be able to provide multiple kinds of discussions, ultimately geared by the social role of the maintainers and the ability to toggle between references to read-only (canonical) texts rather than keeping the discussion within read-write texts.
However, GitHub does provide the interesting case of a highly-networked, highly-transparent working environment. This study has examined the role of a quantified community in argumenting for or against a particular stylistic choice, particularly present in
standard/standard’s strategy, but also present in
prettier/prettier; it is necessary to mention the entangled nature of cross-references to other projects hosted on GitHub. Beyond naming exisiting alternatives168, being able to reference another project on an issue169, or to mention explicitly the name of a maintainer of one given project on a different project170, facilitates the interactions of maintainers171 and allows for an intricate web of intertextualities, allowing discussions happening on a given repository to act as arguments for another repository, or vice-versa. This added layer of complexity is beyond the scope of the current study, but offers a promising field for future research.
calls to “fork” are always the conclusion of an argument
connect to organizational style, communication, etc.
add reference to the CNRS book
develop on how the style guide embodies administrative work -> how? -> CSCW, smoothing out kinks
Nather, Ed (2003-09-12) [1983-05-21], The story of Mel, a Real Programmer, FOLDOC
ref needed - formal institutions (goody?)
simmel, the problem of style
ruskin, seven lamps
sennett, the craftsman
clean code, martin
wendy huy kyong chun
computer power and human reason
the lives of artists
the blog post where they compare picasso, matisse, etc.
more books on professional dev
knuth on style
Brousseau et Moatty (2003), in [https://www.cairn.info/revue-anthropologie-des-connaissances-2012-1-page-21.htm?contenu=article]
G. Hendry, “Public participation in proprietary software developmentthrough user roles and discourse,” Int. J. Hum.-Comput. Stud., vol. 66,no. 7, pp. 545–557, Jul. 2008
wealth of networks
Social Coding in GitHub: Transparency and Collaboration in an Open Software Repository
Gillespie, T. What are platforms?
Influence of social and technical factors for evaluating contribution in GitHub, [https://doi.org/10.1145/2568225.2568315]
Barthes, La plissure du texte
got issues? who cares about it?
Let’s Talk About It: Evaluating Contributions through Discussion in GitHub
M. Hilton, T. Tunnell, K. Huang, D. Marinov and D. Dig, “Usage, costs, and benefits of continuous integration in open-source projects,” 2016 31st IEEE/ACM International Conference on Automated Software Engineering (ASE), Singapore, 2016, pp. 426-437.
Latour, Woolgar, 1979
Jeantet, A., 1998. Les objets intermédiaires dansla conception. Elémentspour une sociologie desprocessus de conception. Sociologie du travail,n°3/98, pp. 291-316
Vinck, D. (2009). De l’objet intermédiaire à l’objet-frontière: Vers la prise en compte du travail d’équipement. Revue d’anthropologie des connaissances, vol. 3, 1(1), 51-72. https://doi.org/10.3917/rac.006.0051
lessig, code is law
Bourdieu, Ce que parler veut dire
Habermas, Theory of Communicative action
Some computational approach to github
Perceived Language Complexity in GitHub IssueDiscussions and Their Effect on Issue Resolution
The Practice of Everyday Life, Michou de Certeau
E. Kalliamvakou, D. Damian, K. Blincoe, L. Singer and D. M. German, “Open Source-Style Collaborative Development Practices in Commercial Projects Using GitHub,” 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering, Florence, 2015, pp. 574-585, doi: [https://doi.org/10.1109/ICSE.2015.74]
sth about bourdieu and symbolic belonging idk
galloway, the interface effect