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

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

    It's come up several times now and it'd be interesting to get some more thoughts on this. Developers consider community opinion as a large metric of what should or shouldn't be merged. They also look at things like how it impacts gameplay, if it improves the code base as a whole, if it needs a lot of staff policing, if it's easy to abuse to break rules, that kind of thing.

    Code quality is non-negotiable and isn't up for discussion. Code added must be of sufficient quality to make it in.

    For the other things though, should devs strictly adhere to community opinion? Should they be making judgement calls based on other factors or only on community opinion?
     
  2. Meyar

    Meyar Retired Worstmin 2015-2017

    We're not a democracy and devs are expected to use sound judgement. If there's a huge outcry (ie significant majority) against a PR, chances are devs will see the reasons why and go "closed"

    As well, just because many people want something doesn't inherently make it a good idea for balance or the code base. Also sometimes people will support something just for giggles.

    If the community majorly upvotes/downvotes something, it should certainly weigh into a devs decision, but not make the decision for them.
     
  3. Jovaniph

    Jovaniph Petty Officer First Class

    I think a good policy would be
    1. Devs can merge any pull request that consist any bugs/fixes
    2. 1 Dev and 1 Seniormin (or higher) must approve a Major PRs (features/tweaks/etc) before it can be merged.
    3. Minor Features/Tweaks can be approved by the Devs.
    4 (bonus): Devs has a final decision on whether a PR can be merge IF the PR's code is not up to standards.
    On that note: Community Opinion should be taken into consideration, but the final decision is decided by the policy I suggested.
     
  4. F-Tang Steve

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

    Why should seniormins get a say in major PRs? Also do I count as a dev and a seniormin?
     
  5. Jovaniph

    Jovaniph Petty Officer First Class

    Good question. Then Another Dev or Seniormin has to approve it.
     
  6. F-Tang Steve

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

    And why should seniormins have any say in gameplay features?
     
    Earthcrusher likes this.
  7. Jovaniph

    Jovaniph Petty Officer First Class

    I don't believe democracy is appropriate when it comes to game development
     
  8. F-Tang Steve

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

    What I mean is, senior admins have nothing to do with code or gameplay features. Why do you think it's desirable for them to now have a say?
     
  9. Meyar

    Meyar Retired Worstmin 2015-2017

    I'm assuming he means headdev.
     
  10. F-Tang Steve

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

    I don't think so, since he said I'd count as either a seniormin or a dev.
     
  11. ТhatOneGuy

    ТhatOneGuy Unathi Species Maintainer

    The only time a senior should be brought in is if it’s lore related. Only time I should be brought in is for very controversial/big changes. Headdev is a Head not a Senior

    Otherwise I think devs have full say on what goes in and doesn’t and should use their best judgement based off what people are saying about the change (if it’s controversial).
     
    Meyar likes this.
  12. mkalash

    mkalash Donator

    There are plenty of objective decisions that developers make which they should be trusted to judge independently. Those decisions are about code. Questions about which features are fun are questions of opinion. Developers have the experience to potentially judge the enjoyment of a feature without seeing it in action. But so does every active player of the game.

    To copy what I told Steve earlier: I trust a chef to know how to cook a fish much better than any layman. But I don't care how many Michelin stars he has; if I don't like the taste of fish, he's not going to make me eat it.
     
  13. Jovaniph

    Jovaniph Petty Officer First Class

    Then just let the devs and headdev make the decisions. There is no reason for anyone else to decide and if no one can decide, the headmin/headdev has the final say.
     
  14. F-Tang Steve

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

    But who should be in charge of if fish should be served and how? You or him?
     
  15. Jovaniph

    Jovaniph Petty Officer First Class

    If you don't like the fish, yell at the chef.
     
  16. mkalash

    mkalash Donator

    I'll order the chicken instead. And if the chef tells me that he won't cook me chicken, well, I'll find another restaurant. The issue lies in if it's the majority of the customers who want chicken, but the chef insists his cooking experience is telling him that the fish would be the best meal. I'm not saying every one will leave in our context, but they'll certainly be upset.
     
  17. Jovaniph

    Jovaniph Petty Officer First Class

    I think it is fair to say that if the development team are blatantly doing poor at improving the game, then they are just asking to be lynched really. However, I see no proof of that so I think i'm okay with the dev team making the decisions.

    edit: And if they are blatantly ignoring the community and not taking them into consideration. Same deal.
     
  18. Meyar

    Meyar Retired Worstmin 2015-2017

    :eyes: Yeah.

    If devs are being shitheels we have a complaint subforum. It's very exceedingly rarely necessary to file one against a dev.
     
    ТhatOneGuy likes this.
  19. Chinsky

    Chinsky Indentured Coder Developer

    [​IMG]

    I have used and will use my gut and subjective judgement when deciding if thing is good or not. Subjective things are subjective, that's why they are called subjective, and not objective, because they are not objective. Subjective things will be decided subjectively, not based on quantifiable objective things.
    Turning devs into static code checker that presses button after number of upvotes is high enough doesn't sound like fun.
    tl;d reee leave me alone
     
  20. Ccomp5950

    Ccomp5950 Retired Staff

    Unless things have changed significantly in the last 3 years you aren't ever going to be able to get a policy on this. We do not have a set direction development is going in, we have volunteers submitting what they think would be fun + some bug fixes every now and again. Without a stated direction there can be no shared idea of what the server needs and what it doesn't so it will be subjective to everyone involved. With a stated direction you are essentially telling the group that doesn't agree to go code elsewhere. So we have the status quo because no one wants to run off coders no matter how shitty, except maybe one offs like goofball.

    Your best bet is some form of oversight for egregious issues with developers (headdev/headmin should be sufficient) or some semi-neutral steering committee that can be appealed to, and even then the point isn't to override but to discuss the merits of each side and try to bring some compromise or suggest changes that can be made to make it appealing to both/all sides of the debate.

    Everything else will just wind up being "have a problem, go to <authority figure>, that doesn't solve it?, go pound sand".
     
    Spookerton likes this.