Bugreporting how-to: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
== Bugreporting | == Bugreporting == | ||
''Bug reporting, the practice of submitting an account of errors, flaws, and failures in software, proposes ways to be involved with technological development that not only tolerates, but necessarily requires other modes of expertise than writing code. Bug reporting is a lively technocultural practice that has come to flourish within free software communities, where Linus’ law “with many eyeballs, all bugs are shallow” still rules.<ref name="ftn340">Eric Steven Raymond, “The Cathedral and the Bazaar,” accessed July 1, 2019, [http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/index.html http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/index.html],</ref> The practice is based on the idea that by distributing the testing and reporting of errors over as many eyes (hands, screens, and machines) as possible, complex software problems can be fragmented into ever smaller ones. By asking users to communicate their experiences of software breakdowns effectively, bug reporting forces “the making of problems” through a process of questions and fragmentation.<ref name="ftn341">As Simondon notes, “living is itself the generation of and engagement with problems.” Gilbert Simondon, ''L’Individuation à la lumière des notions de forme et d’information''(Grenoble, Publisher 2013).</ref> It exposes so-called bugs to a step-by-step temporality, to make even the hardest problems small enough to be squeezable,<ref name="ftn342">In the context of technical bug reporting, squeezing refers to fixing.</ref> as they eventually are reduced to nothing more than ''tiny'' bugs.'' | |||
[[File:Scoping.png|thumb|600px|frame|none|Scoping the issues with Immunity Certificates collectively]] | [[File:Scoping.png|thumb|600px|frame|none|Scoping the issues with Immunity Certificates collectively]] | ||
''In order to streamline the process of such squeezing, many software platforms have been developed to optimize the cycle of bug reporting and bug fixing.<ref name="ftn343">Issue trackers are increasingly being integrated into software versioning tools such as git, following the increasingly agile understanding of software development.</ref> “Issue trackers” help developers to separate bug reports from feature requests. A “bug” is a fault or an error that responds to what is already there; a “feature request,” on the other hand, is a proposal that adds to the project-as-is; it extends an existing feature or ultimately necessitates the rethinking of a software’s orientation. It is obvious that in such a technosolutionist framework, reports will attract attention first, while requests have a lower priority. Once identified as such, a bug can then be tagged as “critical” (or not), assigned to a specific piece of code, a software release, a milestone, a timeline, or a developer who then will need to decide whether it is a syntax, run-time or semantic error. From then on, the bugs’ evolution from “reported” to “resolved” will be minutely tracked.'' | |||
[[File:Bugreporting.png|thumb|600px|frame|none|On-line discussion on immunity certificates]] | [[File:Bugreporting.png|thumb|600px|frame|none|On-line discussion on immunity certificates]] | ||
''The issue with issue trackers and with bug reporting in general is that these are by definition coercive systems. Issues can only be reported in response to already existing structures and processes, when “something is not working as it was designed to be.”<ref name="ftn344">“Bug: Definition—What Does Bug Mean?”, accessed July 1, 2019, [https://www.techopedia.com/definition/3758/bug https://www.techopedia.com/definition/3758/bug].</ref> But what if something (for example, in this particular case, a geocomputation toolkit) is not designed as it should be? Or even more importantly, what if geocomputation should not be designed, or it should be actively undesigned and not exist at all? Or what if there were no way to decide or define, in advance, how something should be without making an authoritative gesture of prejudgment and imposition?'' | |||
''Bug reporting tightly ties users’ practices to the practice of development, making present the ''relations'' of software––it is a mode of practicing-with. Like Haraways’s situated practice of writing, figured by Maria Puig de la Bellacasa as a “thinking-with” and “dissenting-within”, bug reporting makes apparent that software does not come without its world.<ref name="ftn345">See Maria Puig de la Bellacasa, “Nothing Comes without Its World: Thinking with Care,” ''The Sociological Review'' 60, no. 2 (2012):'' 197–216; Donna J. Haraway Staying with the Trouble: Making Kin in the Chthulucene'' (Durham: Duke University Press, 2016); and Kathrin Thiele’s chapter in this publication.</ref> Dissenting-within figures as both an embedded mode of practice, or speaking from within open-source software, problematizing an idea of a critical distance; but also has an “openness to the effects we might produce with critiques to worlds we would rather not endorse.”<ref name="ftn346">Maria Puig de la Bellacasa, “Nothing Comes without Its World: Thinking with Care,” 205–206.</ref>'' | |||
From: Rocha, Jara; Pritchard, Helen V., and Snelting, Femke “We Have always been Geohackers.” In ''Volumetric Regimes: Material cultures of quantified presence'', edited by Possible Bodies. Open Humanities Press, forthcoming. | |||
Revision as of 16:34, 16 November 2021
Bugreporting
Bug reporting, the practice of submitting an account of errors, flaws, and failures in software, proposes ways to be involved with technological development that not only tolerates, but necessarily requires other modes of expertise than writing code. Bug reporting is a lively technocultural practice that has come to flourish within free software communities, where Linus’ law “with many eyeballs, all bugs are shallow” still rules.[1] The practice is based on the idea that by distributing the testing and reporting of errors over as many eyes (hands, screens, and machines) as possible, complex software problems can be fragmented into ever smaller ones. By asking users to communicate their experiences of software breakdowns effectively, bug reporting forces “the making of problems” through a process of questions and fragmentation.[2] It exposes so-called bugs to a step-by-step temporality, to make even the hardest problems small enough to be squeezable,[3] as they eventually are reduced to nothing more than tiny bugs.
In order to streamline the process of such squeezing, many software platforms have been developed to optimize the cycle of bug reporting and bug fixing.[4] “Issue trackers” help developers to separate bug reports from feature requests. A “bug” is a fault or an error that responds to what is already there; a “feature request,” on the other hand, is a proposal that adds to the project-as-is; it extends an existing feature or ultimately necessitates the rethinking of a software’s orientation. It is obvious that in such a technosolutionist framework, reports will attract attention first, while requests have a lower priority. Once identified as such, a bug can then be tagged as “critical” (or not), assigned to a specific piece of code, a software release, a milestone, a timeline, or a developer who then will need to decide whether it is a syntax, run-time or semantic error. From then on, the bugs’ evolution from “reported” to “resolved” will be minutely tracked.
The issue with issue trackers and with bug reporting in general is that these are by definition coercive systems. Issues can only be reported in response to already existing structures and processes, when “something is not working as it was designed to be.”[5] But what if something (for example, in this particular case, a geocomputation toolkit) is not designed as it should be? Or even more importantly, what if geocomputation should not be designed, or it should be actively undesigned and not exist at all? Or what if there were no way to decide or define, in advance, how something should be without making an authoritative gesture of prejudgment and imposition?
Bug reporting tightly ties users’ practices to the practice of development, making present the relations of software––it is a mode of practicing-with. Like Haraways’s situated practice of writing, figured by Maria Puig de la Bellacasa as a “thinking-with” and “dissenting-within”, bug reporting makes apparent that software does not come without its world.[6] Dissenting-within figures as both an embedded mode of practice, or speaking from within open-source software, problematizing an idea of a critical distance; but also has an “openness to the effects we might produce with critiques to worlds we would rather not endorse.”[7]
From: Rocha, Jara; Pritchard, Helen V., and Snelting, Femke “We Have always been Geohackers.” In Volumetric Regimes: Material cultures of quantified presence, edited by Possible Bodies. Open Humanities Press, forthcoming.
- ↑ Eric Steven Raymond, “The Cathedral and the Bazaar,” accessed July 1, 2019, http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/index.html,
- ↑ As Simondon notes, “living is itself the generation of and engagement with problems.” Gilbert Simondon, L’Individuation à la lumière des notions de forme et d’information(Grenoble, Publisher 2013).
- ↑ In the context of technical bug reporting, squeezing refers to fixing.
- ↑ Issue trackers are increasingly being integrated into software versioning tools such as git, following the increasingly agile understanding of software development.
- ↑ “Bug: Definition—What Does Bug Mean?”, accessed July 1, 2019, https://www.techopedia.com/definition/3758/bug.
- ↑ See Maria Puig de la Bellacasa, “Nothing Comes without Its World: Thinking with Care,” The Sociological Review 60, no. 2 (2012): 197–216; Donna J. Haraway Staying with the Trouble: Making Kin in the Chthulucene (Durham: Duke University Press, 2016); and Kathrin Thiele’s chapter in this publication.
- ↑ Maria Puig de la Bellacasa, “Nothing Comes without Its World: Thinking with Care,” 205–206.