@roaldarboel And I'm not sure a formal taxonomy is necessary. I have a section on my cv where I list all the journals and organizations I reviewed for, and I can imagine putting a section for all the FOSS projects I contributed to, defined as I see fit, or in accordance with how the repo's maintainers attributed my contribution in the release notes.
@roaldarboel Regarding roles of reviewers and original maintainers, we may be talking across each other. I don't think I see such a sharp distinction between reviewers and devs, I generalize all as contributor. Providing critical feedback, committing code, testing etc all bleed into each other. I'm envisioning a way of recognizing when and how contributors improve a code base
@roaldarboel 3- Git generally places an emphasis on original code creators, which may relate to its origins as a tool designed specifically to assist with linux development. Git exists to manage contributions, not to redistribute power. The social model is necessarily impacted by the tech platform it is based on.
@roaldarboel I'm a bit confused about distinguishing pre/postprint since in a situation where the notion of printing, i.e fixing dynamic things to a stable state for purpose of reference, is already very confusing. It may relate to a potential confusion between outcomes and processes
@roaldarboel 2- I think a lot of research software is in fact developed for specific purposes, but in the guise of being general purpose. Its good practice to ensure that its usable by others, or even by its creators in the future, but the software is ultimately borne out of necessity and opportunity in the context of a bounded research project. I think this is a broader institutional problem relating to grant-getting, following trends, and a pressure to come out with immutable outcomes.
@roaldarboel Thanks for engaging! I know its the weekend in most of the world so there's definitely no obligation to post in reply. Also, sorry for the potential thread monster that might ensue, my instance has a relatively small character limit.
1- I agree that peer-review does a lot of things, in terms of traditional papers and software. I like your thinking in terms of aspects rather than categories, which accounts for these examples you mentioned bleeding together
@roaldarboel If I were to re-jig your original idea, I'd make it so that *releases* serve as the boundary markers where a development phase is completed and credit given to contributions. This serves a space to demonstrate and justify the value of issues and other inputs as a collective contribution, and provides a space for more nuanced accounting of who did what, how the work was carried out, who supported or took charge, etc
@roaldarboel Also, the power of the anarchic wisdom of crowds is a myth. All open source projects have some sort of community norms or contribution structures, some extremely rigid (linux kernel is very militaristic), some being simply "sole maintainer non-periodically pushing fixes to their own repo", centralized around a core team of paid devs, casual commits among friends. No model is correct, but some may be more or less suitable for specific kinds of work Flexibility is key.
@roaldarboel My next thought is that the journal articles that come out of code development aren't just currency for promotion and hiring, but also demarcate core membership in the community and set a terminal date on the project's timeline. Papers are therefore functional boundary markers. They allow us to end a funded project and move on to the next one. They allow us to justify the time we dedicate working toward a particular goal and afford the ability to indicate that we achieved the goal
@roaldarboel My initial thought is that the value proposition is unclear. What value do you think peer-review actually provides? What values do github issues provide? Do they do the same things? Do they provide the same kinds of value? What _kinds_ of issue are you talking about here? What about issues that simply request features or fixes that are not accompanied by substantial code contributions? What about offline or off-platform discussions?
@roaldarboel I'm very interested in this, this is something @joeroe and I touched on in our recent paper (https://doi.org/10.11141/ia.67.13)
Modern science relies on (open source) software and hardware, but whereas creating tools (writing code) can be turned into academic currency (papers), there is currently no incentive for researchers to provide feedback and improvement suggestions for tools despite how valuable these contributions are to the scientific community as a whole. One possible way forward would be to treat "issue creation" and other Git-based activity as an acceptable form of peer review.
This is an issue and idea I’ve been thinking about for a while. I’d love to flesh it out into an actual set of actionable proposals/suggestions, as well as figuring out which (technological) hurdles would need to be overcome, in a opinion-styled paper - could anyone be interested in working on this together with me?
Please share!
My colleagues @grimalkina, @CSLee, @flourn0, and I are excited to announce a new project: The Developer Science Review! https://dsl.pubpub.org/
The Developer Science Review is a scientific overlay journal highlighting empirical research that the scientists and software engineers in the Developer Success Lab think is relevant for people interested in the science of #DeveloperThriving and #DeveloperExperience.
@OSSci You might be interested in this recent paper I co-authored: https://doi.org/10.11141/ia.67.13
Getting closer to a first draft of the Voyager book! Chapter six next.
Science is Broken?
New article on the role of “Scandal in Scientific Reform” by @penders.bsky.social
#MetaSci #STS #PhilSci 🧪
Few quotes 🧵
RE: https://bsky.app/profile/did:plc:oox2wsu7wc67iszhpy364udn/post/3kxnvrqv4yq2z
@khinsen You might be interested in a new paper I co-authored with @joeroe on open source software development practices in archaeology https://doi.org/10.11141/ia.67.13
@zackbatist @joeroe This is an important paper that validates what I think many have long suspected. At CAA 2016 I gave a 'provocation' talk on "Open Source: we're doing it wrong" that made the point Open Source is not about building software, but about building communities. It's the only sustainable model for building a lasting ecosystem. Until we create our own KDE/Gnome/Apache-like community, we'll just keep falling well short of what could otherwise be possible.