Change background image
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Developer Judgement Metrics

Discussion in 'Policy Discussion' started by F-Tang Steve, Mar 28, 2018.

  1. Chaoko99

    Chaoko99 Research Director


    This number usually floats around 40-50. Can we please not slow this down even more?
  2. LorenLuke

    LorenLuke Commanding Officer

    Is it a developer's responsibility or that of community members?
  3. Spookerton

    Spookerton Public Kohai № 1 Staff Manager Manager Senior Administrator Community Moderator IPC Species Maintainer Donator

  4. LorenLuke

    LorenLuke Commanding Officer

    I wasn't aware that it's against forum rules. And my question is still one I'd like answered.
  5. Atlantis

    Atlantis Retired Staff

    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.
  6. Banditoz

    Banditoz Senior Enlisted Advisor

  7. LorenLuke

    LorenLuke Commanding Officer

    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?
  8. afterthought

    afterthought Developer

    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.
  9. Atlantis

    Atlantis Retired Staff

    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.
  10. F-Tang Steve

    F-Tang Steve Game Administrator Developer Serpentid Species Maintainer Deputy IPC Maintainer Deputy Diona Maintainer Wiki Maintainer

    You haven't been a Dev for ages afaik. I'm not sure why the forum tag is still there?
  11. Atlantis

    Atlantis Retired Staff

    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.
  12. Ozwell

    Ozwell Retired Staff

    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.
  13. Sabira

    Sabira Head Developer Donator

    Marines were head admin decision, AI was head admin decision, sprites were ours. Check your facts.
    Atlantis and Earthcrusher like this.
  14. Ccomp5950

    Ccomp5950 Retired Staff

    Oh, my bad. Mar 28 looked so much like May 28 to my old, and probably not entirely sober, eyes.