Closed mathemage closed 4 years ago
Hey @ababaian
I have several comments on the basics of good behaviour in Open-source software (OSS) world:
@ababaian changed the title
PR for #9: Instance doesn't signal the scheduler when shutting downUpdate documentation
You never go around and rename other people's issues, pull requests (PRs), branches, commits etc. I also don't mess around your repository by changing titles of your tasks, PRs, issues or other stuff that you work on personally. It gives off an authoritarian impression as if all the other maintainers were under your dictatorship.
@ababaian marked this pull request as ready for review
You never remove "WIP" label/convert draft PR to a "ready" (normal) PR. Those things are exactly the very tools which the PR author uses to express that he hasn't finished his work and doesn't wish the PR to be merged, closed or treated as completed. That's basic logic and common sense.
@ababaian merged commit 2cde5ca into master
For the same reasons as in the previous point, you never "un-draft" a PR and just merge it, at least not without previous discussion with the PR author. Such un-compromising behaviour again sends out a signal that you can do whatever you want without preceding consultation with your collaborators.
@ababaian deleted the 9-instance-doesnt-signal-the-scheduler-when-shutting-down
I had to modify the documentation because Github doesn't allow to open an empty PR (without any commits/any changes to the code). So I had to find some changes in the code (of documentation) to commit in order to be able to create a PR. Which I made immediately as a draft PR and "WIP" to display that it's not finished - and those are exactly the 2 tools to use to explicitly express that intention for incompleteness. Now that you closed the PR and merged my commits into master
, I'd have to find another change to commit just to open a new empty PR to be able to work on this again. That's really frustrating and deeply inconsiderate of you. Please always think the consequences of your action, especially how it affects the culture for the developers of your project.
I was still working on this issue. If you wished to fast-forward the fix, you could have opened another (concurrent) PR dealing with the issue, not closing my PR and thus discarding my work.
Read some guidelines on how to behave in the OSS world.
I am not sure if this is an honest mistake or you did this on purpose but such behaviour (of an authoritarian dictatorship) appears impolite to an external observer. It bears the danger to discourage potential contributor and other volunteers who'd be otherwise willing to sacrifice their time to help and work on your project.
Hi @mathemage All of us involved in Serratus are novices at some aspects of the project -- cloud computing, managing a complex open-source project, virus biology and so on. Nobody is an expert at everything, and all of us are trying at least some things for the first time. The leaders of the project are incredibly busy and have very limited bandwidth for doing anything not absolutely necessary for making progress. In my case, I have never worked on a collaborative open source project. IMO @ababaian is indeed a dictator, but a benevolent one, and a necessary one for achieving the goals of the project. He has taken the initiative to start this project, and has done an incredible job moving it forward in short time and recruiting Amazon to donate AWS credits for performing the SRA search, without which this could not happen. Decision by democracy or by committee would not work here; benevolent dictatorship is the optimal solution in this case. We appreciate constructive feedback, but please start from the assumption that we have good intentions and are doing our best. We welcome contributions from anyone who can help.
@mathemage I understand where you're coming from. Best practices in regards to open source is something we are all striving for in this project. But as @rcedgar put it, all parties involved are learning given the broad scope of tasks.
I had to modify the documentation because Github doesn't allow to open an empty PR (without any commits/any changes to the code). So I had to find some changes in the code (of documentation) to commit in order to be able to create a PR
This doesn't seem like good practice. Changes made by a pull request should directly address the issue at hand - any unrelated changes can be proposed in a separate PR.
Every OSS project must establish its own "best practices" given the context of the project. I think the best step forward would be to come up with a solid set of standard practices to document in the wiki/CONTRUBUTING.md to minimize any miscommunication in the future.
Mea culpa
@mathemage. I say it all the time, I'm a biologist not a developer so I have no idea what I'm doing on that side of things, I only want to get the science done as best as possible. I'll take a look at the OSS guidelines when I get a chance, always a good idea to improve and learn.
PR fixes #9