Discussion in 'Policy Discussion' started by F-Tang Steve, Mar 28, 2018.
This number usually floats around 40-50. Can we please not slow this down even more?
Is it a developer's responsibility or that of community members?
@Ccomp5950 @Chaoko99 @LorenLuke
Just in case you hadn't noticed, you're doing necromancy.
I wasn't aware that it's against forum rules. And my question is still one I'd like answered.
Well, to answer your question, the responsibility is on both sides.
If a PR is technically mergeable (no conflicts) developers are responsible for reviewing and approving/requesting a change.
On the other hand, it happens pretty often that a PR is reviewed and changes are requested (or a conflict occurs), and then it is the PR's authors responsibility to return it to mergeable state.
I wouldn't call large amount of open PRs a bad thing - as long as the PRs are active. If they are not (which tends to happen) they are closed after some time by developers.
No, it's just @Ccomp5950.
While I'm not saying such occured here, I've had issues with other code bases where I'd have a PR up, ready to review three weeks, only to have a Dev slap a 'cannot merge' on it much later when it was damn well ready and could have been easily merged prior.
Is that behavior negligent? Is it punishable? Who would be punished? All the devs? All those not on leave?
I acknowledge there's no good system in place to answer any of these questions, and no real way to create a system that will. What then is there to do? What metrics can we create to combat this behavior, should it arise or any attitude that involves them passing over things they don't like.
TL;DR what behavior can devs, unique to the purview of their developer duties, be punished for?
Complaining about the devs is pointless. Doing it here on a random forum thread is doubly pointless. I've had many PRs that have been merged very quickly, and also a few PRs that took forever to see review. I've had many helpful comments/conversations with devs, and a few unhelpful ones. There is nothing that can be done about this, other than not contribute PRs to the repo.
If I have problems with a specific dev, I can talk to them directly or open a staff complaint thread (but I don't). But generic complaints about the process aren't going to do anything, because there are no solutions here. If you get rid of some devs, you only make the problem worse, and forcing additional devs will reduce the quality of the codebase even further (the qualified people are already devs).
Devs should be punished for inappropriate community behavior, breaking the (few) explicit rules the dev role has (e.g. approving own pr), and anything else the head dev feels like.
The behavior you describe happens every now and then. I believe it can have few causes
- There is simply no developer available to review your PR - developers aren't paid for this job, and their time is limited. Possible solution to this is to increase amount of developers on the repository, but unfortunately only few people qualify for that. Furthermore, as dev applications were kind of moved into gray zone of unknown again, there is no clear procedure on how to become a member of the development team (i am a prime example of this gray zone, i've been stuck as half-dev for quite some time, ever since the developer/maintainer change was reverted). Making official and transparent way to enter the development team would be a step in the right direction, i believe.
- Your PR is simply too large - i learned this the hard way, the more things you stuff into a PR, the higher chance you have that nobody will review/merge it in time, as longer PRs in general take longer to review. It also increases chance of a merge conflict. Even a small controversial/contentious change can then cause otherwise perfectly okay PR to go into a "review deadlock". When possible try to break up larger changes into few smaller independent PRs.
- You touched something complex in a way where nobody wants to sign under your changes. Some atmospherics code can be an example. Can'
t talk about other developers, but when i had repo access i avoided reviewing things where i wasn't sure how the mechanic works.
- Developers don't like your feature - As much as i don't like it, everyone (including me! not trying to offend anyone here) uses certain level of personal opinions when reviewing changes. Some people do this more, some do it less. With current relatively small dev team size, however, it is very easy to run into situation where your change is okay code wise, but isn't merged because nobody from the dev team wants to merge it. Solution would be the same as in first point - increase amount of developers, so more independent opinions can be present.
You haven't been a Dev for ages afaik. I'm not sure why the forum tag is still there?
Going to drift slightly into offtopic area here but to answer you, @F-Tang Steve
Haven't heard an official statement from xales on that so far so as my perspective goes, i am still waiting for a decision. I had some nasty stuff going on during first few months of this year, after that i've contacted xales (on 5th March), explaining that i should be available now, and asking on how we are going to proceed (last information i had at that time was that there is going to be some test period for those of us which were hit by the maintainer/developer merge). Xales said something along the lines that he's going to check with the other developers and then let me know. I've asked few more times during the time, but xales apparently doesn't have the time to go through the mail right now.
Developers use community opinion to help in the decision making process? This somewhat surprises me. Look at what's happened recently that went kind of controversial: marines, ai removal, sprites (pls), and probably a couple other things. I don't need to say anything else.
Marines were head admin decision, AI was head admin decision, sprites were ours. Check your facts.
Oh, my bad. Mar 28 looked so much like May 28 to my old, and probably not entirely sober, eyes.
Separate names with a comma.