BizHawk
BizHawk copied to clipboard
TASEmulators
Hostile Bug Report Responses are Hurting the Project
Natt's responses to the recent NES mapper issue have led to me having to field a very frustrating complaint about his behaviour. I shouldn't have to do this. Over the years I personally have become de-sensitized to it, as I'm sure may other contributors have, but you should know that ordinary users and other general observers have not. In particular, fiskbit's work has directly benefited NESHawk in ways that I am incapable of doing on my own, so you are even alienating people who you don't even know are important contributors.
To at least hopefully bring attention to this issue, I am withdrawing from this project and will no longer be contributing.
I'd like to note something directly to Natt. See from this issue: #2067
I'm frustrated, but I have good reason to be.
It's a good thing being frustrated when things don't work, because it means that you care about the project. However, being frustrated doesn't necessarily imply assuming bad faith of others, which is counterproductive. In the same issue I've mentioned, you assumed Alyosha to be responsible for having broken something, however as TiKevin explained there, it was just due to moving from gambatte to gambatte-speedrun, for which it's reasonable that it caused consequences that Alyosha couldn't foresee, and that he couldn't instantly understand how to fix by himself.
Now, how would you feel if someone accused you of being responsible of something that you're not, while also receiving personal attacks? See, some people react to that by simply losing motivation to contribute. And this is a major problem, because for this project each contributor brings unique progresses for the project. Yeah, maybe with some work and luck you can figure out a replacement or maintain stuff in their place, even if it would never be the same. But you can't replace the manpower lost, which still means losing a chance for the project to grow. So if you really care for this emulator, you could try to be more functional with the personal interactions, to say the very least.
However, if you think there is any contributor that would be better gone, by all means talk about it openly. Bring all your evidences for the damages that you think they brought. Just make sure to bring objective data and not put your personal feelings about it.
In my opinion there are core problems with the contribution methodology of this project that run contrary to standard open source development practices and this has contributed to the friction experienced between devs. There are experiences with individual devs that could be named but it's not relevant when the issue is exacerbated by the project's design philosophy.
- Nobody, not even the most seasoned devs should be committing directly to the main branch. This is a mature project with a regular release cadence, not an unused experiment. Every commit should be PR'ed and have at least one approval from another developer before merge.
- The main branch should be renamed to "main" from "master" as this has become a common open source convention and hurts nothing to change.
- A Contributing guideline should be implemented similar to the one created for TASVideos which links out to a Code of Conduct, local development setup (the readme), coding conventions used in the project, and frontend design conventions. This could then be used as an authoritative reference to resolve disputes cleanly within issues and PR reviews.
Without structured contribution guidelines and code reviews this project will continue to alienate seasoned developers who are used to a welcoming and team-building atmosphere in an open source community.
Nobody should be committing to the main branch? I don't see how well that would work out, given how segmented the project is itself, and how many submodules there are. Primarily it could encourage moving/creating cores to/in submodules like ported cores often are. Which at that point the only "review" will be "reviewing the submodule update." Remember too there aren't a ton of developers, and we have different skills which can make a difference to however meaningful a review actually is.
I can see benefit in making some parts of the projects more "needs to be PR'd." Something like TAStudio (given how messy that is itself and it being critical for TASing in every core) would be agreeable, maybe some other parts. Also making changes to parts of the project you don't normally touch (e.g. my PR (https://github.com/TASEmulators/BizHawk/pull/3170) to fix the SXROM issue which started this thread, as I have little knowledge of the NES or its mappers and the mess that is iNES parsing. I was completely wrong with my first approach due to this, and made a proper approach the second time). Of course enforcement would end up needing to be "informal" since I don't think you can exactly have some formal measures done for this.
The main to master thing is a common open source convention? It's really more that GitHub changed that to be the default branch because master is bad due to connotations to slavery? Which itself is questionable/silly. Git itself still has the default branch be master, and is why my own repos have a master branch instead of a main branch, as they are started locally and I'm too lazy to go change it.
Really however, that change is more or less just an annoyance and I wouldn't care for it, of course that is why people don't go change default main to master, and why they typically don't change the default master to main.
A code of conduct I would fully welcome here, along with other goodies in the 3rd point. Of course may want to only include "style" within the frontend as the backend can go fuck all with that, using their own style for each core, unless you want to volunteer for changing the style of cores to match the frontend, then maintaining that with every update, and also ruin one of the central points of the Nyma project (sarcasm).
mainline git itself is working on changing master to main as well for new defaults and I've seen a lot more repos switching. I think my point 3 should be the focus here though. Having documentation available for contribution including a code of conduct can do nothing but help the project
Switching to PR-only is not how you make PR reviews and issue feedback less hostile. More PRs - more feedback - more hostility. Code of conduct may help more, but it requires active maintainers to always be there to enforce.
Feedback is not inherently hostile. It doesn't have to be dismissive, insulting, or abusive, which are the things that should be addressed. Most reasonable people don't want to subject themselves to such negative treatment. I don't know whether there are improvements to be made to the BizHawk review process, but I suggest focusing here on ways of making this a more welcoming and encouraging environment for users and contributors so people continue being willing to engage. Right now, at least for me, this project is not meeting that standard.
I have no context on this thread but my $0.02 is it's not necessarily an isolated case. I've felt some negative interactions on this project in the past (whether real or imagined). And it only takes a couple negative interactions to really push away a dev, since the people who contribute here are just hobbyists who can just work on a different emulator or project if it stops being fun to participate.
+1 to the recommendation for a code of conduct as a tool to avoid this kind of issue, and set the tone for future interactions
I'm ambivalent on the idea of a code of conduct, but if anyone cares enough to draft one, that will be GitHub's community checklist done (apart from a 1-minute fix of checking this box on this page).
As for code and contribution policy, I've just added a contributing.md which can walk you through contributing to EmuHawk. It's a bit sparse on other projects, and it doesn't have a lot of detail about the processes around contributing and managing the repo, but it's a start. I might make a separate Issue for formalising those since I have some ideas but don't feel they belong here.
