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

Gameplay and "Controversial" change policy

Discussion in 'Policy Discussion' started by xales, Nov 29, 2017.

  1. xales

    xales Host Game Administrator Developer Community Moderator

    Hey everyone,

    First off, I feel I haven't said this enough. I've been quite busy with some stuff lately and haven't been able to give the community an appropriate amount of attention, especially given what's been happening as of late. However, I've accomplished most of what I need to do, and should have time now to dedicate back to the game and community.

    Regarding the events of late: there's been a lot going on, and undoubtedly a lot of strong feelings coming from it. While there remains individual issues and things that I'll be following up with certain people directly, all of the problems seem to be stemming from two main problems. First of all, I never did create a sufficient definition of the new difference between the developer and maintainer role, and that's something I'm going to remedy. Second, and something that's been an issue for a long time, is the lack of a good framework for dealing with the gameplay side of our duty. The developer role is two-sided: on one hand, we should be creating well-written, quality features, and ensuring that the same is what makes it into the repository. At the same time, we have to make decisions about when things that fundamentally alter some aspect of the gameplay are appropriate or not. And in the case where that is controversial, within the team or the wider community, something that has happened increasingly often as of late, we do not have an adequate system of handling it. Historically, someone from the highest levels of the staff team, be it an administrator or developer, would make decisions with some degree of isolation, but many people don't like this approach as it makes many feel as they are without a voice, and it breaks down if there aren't people available and prepared to make these decisions, and handle the fallout from those who disagree.

    Moving forward from here, I want to improve both of these things, so that the team can be more autonomous and can more effectively integrate feedback from the wider community. I'm going to start with the gameplay issue, as the distinction it introduces will enable better defining the distinction between the roles.

    Handling controversial gameplay changes

    First, let's define a gameplay change. This is something that substantively alters the experience a player might have when interacting with something. From, yes, changing an item's size or damage value, to an item's name or sprite, where and when it spawns, and so forth. A non-gameplay change would be something akin to refactoring code, cleaning up the implementation for a features, and so forth. Right now I'm going to explicitly not include species-specific functionality, as for the time being this will continue to be under the authority of the relevant species maintainer, and while these changes may opt-in to this process, they are not obligated to it.

    Second, let's define controversy here. Taking a step back, most changes are developed, tested (I hope), and introduced as a pull request on Github. So, we'll need to build a definition of this term using what we can garner from Github. The first way to indicate something as controversial would be an explicit opt-in by the author, by applying the determination themselves or asking for someone on the team to do so, on Github or directly. The second way would be through an objective assessment of the development team, ideally involving discussion between multiple members prior to a determination being made. Such a determination should not be made within the first 24 hours of a pull request being made, but a pull request should also not be merged by anyone in this time frame unless it is critical (in which case, it should not be a gameplay change, and reverts should always be preferred in this case). To aid in making these determinations, here are some guidelines, which are not absolute but a strong suggestion that something is probably controversial:
    • Significant "thumbs up" and "thumbs down" top-level reactions, with strong participation (>5 total in 24 hours) and at least 25% "thumbs down"
    • Multiple comments on the PR indicating dissent with some descriptive explanation of why they oppose it
    • Feedback from others on the team
    Regarding the distinction between developers and maintainers making these decisions: to reflect that a goal of the developer role is to aid in learning more the code review and stewardship role, I will allow and encourage both developers and maintainers to make these determinations. However, I would like both developers and maintainers, but developers especially, to make this determination only with a relatively high confidence in it being a legitimate controversy, and to do so with support of others. Regardless of your role, I strongly suggest speaking with others on the team before coming to a final decision here. This is doubly true for developers - you really need to talk to a maintainer if possible before ruling here. As an aside: if there is a feeling that the controversial flag was inappropriately applied, two maintainers may remove it, posting their reasons for making the decision on the PR, and allowing 24 hours more at which point they will jointly re-evaluate it. If after 24 hours further it's not evaluated as controversial, they may leave the tag off and should forward to the Head Developer a summary of who applied it, and the reasoning for it being removed. For what I hope to be obvious reasoning, a non-gameplay change should never be controversial. In the event a gameplay change is determined to be controversial, the controversial label should be applied.

    Now, let's say we have had a gameplay change that's determined controversial. After the label is applied, the person who opened the PR must make a thread following a template in a yet-to-be-created subforum explicitly for this purpose. Regarding the subform, I'd like to defer to the expertise of @F-Tang Steve:
    In addition to this subforum, there will also be a second subforum that maps 1:1 threads in the other, intended to provide a higher-level summary and allow public consumption of our internal discussion on this. It will be viewable to all but only members of the developer team may post there. The posts should summarize the thread and discuss the decisionmaking process we go through. For example, "It looks like most players are okay with this change right now, but there's a few people who are concerned this make it really hard to play as an engineer. Is that going to be a big enough concern to hold the PR? Should we play-test this for a round or two?" The purpose here is two-fold: to show that the discussion had contributes to the decision-making process, and keeps us accountable for what that process is. It also encourages communication amongst the developer team, and ensures we're all on the same page. If, after a thread has had some time to play out (no hard rule here, but I'm guessing it'll probably take about a week before things get messy or quiet), and the developer team is roughly on the same page (this should be virtually unanimous) about how to move forward, then a maintainer may post with the decision and lock the thread, and remove the controversial label on Github. At that point, they may also merge it if it is appropriate to do so. Back to the words of @F-Tang Steve regarding this subforum:
    Both developers and maintainers, as well as the community moderator team, will be invited to moderate the public subforum. In the developer-summary subforum, anyone who firsts posts on the discussion may create the thread, but it shall be up to the PR author to make the first thread in the public area. If after some time they do not make a thread, the PR may be closed.

    In the event that, after familiarizing themselves with the desires of the community through the participation in the thread, there is not a near-unanimous decision from the team, we can resort to doing a poll available only to the team, in the developer-only (but publicly visible) thread. This should be a vote on the best resolution as a representative of what the players want, not your personal opinion. The simple majority will win, and in the event of an unbreakable tie, the decision rests with the Head Administrator, per existing policy. Furthermore, the only veto rights for gameplay changes rests with the Head Developer and Head Administrator, as well as the Host.

    Distinction between developer and maintainer
    Regarding the material distinction between the roles: maintainers have the discretion to merge things at any time, using their discretion and only if necessary. The normal review process is encouraged to be followed outside of critical changes. For gameplay changes, waiting at least 24 hours to merge, even with approvals, should almost always be the case. Developers may, as Github permissions allow, merge with an approved code review, with their merge constituting a second approval. The code review feature on Github, including both approval and change requests, should only be used for code-quality changes. In the event a decision is reached from a controversial feature thread, this may also be expressed to the author by the maintainer who closed the thread in the form of a change request. Otherwise, they should not be used for non-code-quality reasons.

    Nobody should, at any point, merge a PR labelled with controversial or Do Not Merge. The first has well-defined reasons for its application and removal,
    and the second should be used for similar effect, and may be applied by anyone, but only with a post to the PR explaining why it was applied and what the condition is for removal, or at the request of the PR author. Both developers and maintainers may apply DNM, and may remove their own label. Another developer or maintainer may remove the label if the original person who applied it has been given some time to do so, and the condition provided has been clearly met. If there's any doubt, just wait, or get two people to agree to remove it. The reason it was removed and basis for meeting the condition should be posted when it is removed. If you remove the label, you should let someone else merge it, maintainer or otherwise. If a DNM is inappropriately applied, two maintainers may agree to remove it, both posting that they did so, and making the Head Developer aware that a DNM decision had to be overruled.

    Since it needs to be said: developers and maintainers should not be approving their own PRs. You should also not, in general, merge your own PR, unless absolutely necessary. This also applies to PRs substantively the same as one you have recently created, as well.

    I'm sure I've left something out here, so please let me know what you think.

    Suggestions - peanut gallery subforum explicitly for theorycrafting/idea-throwing; feedback threads about new changes stickied here
    Gameplay Changes - this is the subforum mentioned above for public threads regarding controversial changes; old threads may be locked and left here, and will sort down naturally
    Developers - this is a subforum of the game changes forum, visible to all but only developers and maintainers may post (may revisit for other staff)
    Coding - as now, with some cleanup; posts about actually doing the development work
    Content Creation - combination of mapping and spriting, discussion of both; split into subforums if needed

    Let me know what you think of this structure and the naming, as well.

    Thanks for taking the time to read!

    This wall of text brought you to Expert Internet Wall Builders, est. 2011
     
  2. xales

    xales Host Game Administrator Developer Community Moderator

    An aside: this is a near-verbatim copy of a post that I've made in the developer forum, directed at the developer team, regarding a new policy to handle situations where there is widespread disagreement on how to handle proposed changes, especially when that disagreement spreads to the developer team itself.

    I'm curious to hear the feedback that the wider community has before implementing this. Right now, I'm hoping to give it a few days and see what the temperature is, and move forward with trying out the system. We'll re-evaluate it both as a developer team and as the community overall in this thread, and decide if it's the right way to go. I'm sure it's impossible, but it'd be great to have as many people feeling good about the way we handle these things going forward, because they do have quite a wide-ranging effect on the experiences that people have in the game.
     
  3. mkalash

    mkalash Donator

    I don't think a restructure of the development subforums are necessary.
     
  4. StrategicImportance

    StrategicImportance Senior Enlisted Advisor

    So, the gist of it is as I understand it (since this is a very long post):
    There is a new PR.
    Dev team decides between itself on its fate, one of them can mark the issue as controversial.
    If the PR is marked as such, community gets to debate the issue in a thread made by PR author.
    Reasoning and commentary is taken in instead of a "I like it/don't like it" voting.
    Dev team re-votes based on community response if it happened and decides the fate of the PR.

    A few things:
    Time and again, you see PRs that have an idea of "I made this feature, I love my code/idea, this is what it does". The author would not list the existing problem within the gameplay and detail how exactly will this solve this problem, they would just skip straight to their solution. This pinned post describes what I mean in detail as "clear design outcomes and goals" and why it's needed.
    Not having the initial problem impedes healthy discussion considerably. I move for making this explanation a hard requirement in case of a controversial-PR-thread.

    Where is the guarantee that they will be unbiased? We already had maintainers ignoring community opinion and just pushing their changes.
    Only the maintainers have this power? Not the public and not the developers?
    Can one of those removing mantainers be the PR's author?
     
  5. Meyar

    Meyar Retired Worstmin 2015-2017

  6. mkalash

    mkalash Donator

    The only thing you've misunderstood is the committee nature of it. A single developer gets to decide if a feature is controversial, based on the given guidelines. Should others on the team disagree, two other developers can agree to remove the tag together. The developer who marked the change as controversial will judge if the community decides for or against it, and again two other developers can override.
    Definitely not. Handling your own PR will always be the sacred no-no.
     
  7. StrategicImportance

    StrategicImportance Senior Enlisted Advisor

    This is way more clear and simplier than the wall of text above, thanks.
     
  8. Spookerton

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

    I totally understand the idea behind "no polls, all commentary below an arbitrary level of defined participation is not useful and will be removed", except that exactly as we've seen with some recent controversial changes, "I don't like this change", "This doesn't seem like an improvement", and several other kinds of brief comment are perfectly reasonable contributions under many circumstances.

    The idea of weeding out opinion posts because they don't comment on the mechanical properties of the thing being discussed at length is a poison, has been a poison, and will continue to be a poison. The reason people were complaining about it being done without a justification in the rules wasn't so that it could be established in the rules as standard practice.
     
    Meyar likes this.
  9. Meyar

    Meyar Retired Worstmin 2015-2017

    After a re-read, yeah, this. Sometimes I just vote without injecting an echo of an earlier opinion or don't want to influence how another feels.
     
  10. Sabira

    Sabira Head Developer Donator

    Is the OP a result of a unified effort by all of the active devs? If not, what are their opinions on it? (it being the OP)
     
  11. StrategicImportance

    StrategicImportance Senior Enlisted Advisor

    Take the recent "disable borg remote blowup" PR. There were a lot of posts explaining why this a remote Power Word Kill is frustrating for a cyborg player and poisonous as a feature on a HRP server. There vote split was almost 50/50 and there were barely any arguments why this should stay and the points made by those against the feature mostly went unaddressed. It felt incredibly frustrating getting "No" votes but no accompanying explanation despite your best efforts to discuss.

    There clearly has to be some middle ground between thought-out commentaries and silent "lol no they're OP already" vote counting.
     
    Kelenius likes this.
  12. F-Tang Steve

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

    The idea is to not have scrapping a PR and starting a new one with changes being the default option anymore. Currently, polls tend to poison a PR if they're mostly no, and even if it changes significantly the poll doesn't change to represent that. The idea of comments is to, instead of having things be a straight yes or no, identify the specific issues people have with the PR so it can be adjusted and worked into a compromise. If changes are made based on posted opinions and then the PR is reassessed and merged, the old poll has been used to speak poorly of the devs/maintainers involved with the process.

    It's totally legit to not like something and to post it, but adding a few more words to say what it is you don't like is infinitely more useful. "I don't like this" doesn't tell us much and doesn't give us a way to try to make a compromise. Saying "I don't like this because engineers need to carry more fuel" can be used to make the PR better and try to make everyone halfway happy rather than a strict yes or no.

    One way that would help more people contribute would be to have likes in the subforum count effectively as a "I support this post" thing so we can figure out what action to take.
     
    StrategicImportance likes this.
  13. LorenLuke

    LorenLuke Commanding Officer

    What provision is given if someone else finds the PR controversial who is neither maintainer or developer? They're, by first dibs policy, prevented from making a thread on the forum about the PR, and are limited to merely commenting on the PR.
    It's reasonable to assume that not everyone who frequents the forums also 1) looks at the git regularly, 2) has a GitHub account. Ergo, there might be times where a PR would be "quietly" merged, as the author sees no controversy, it's code sound and approved, and flies under the radar due to the fact that, despite a few negative comments, it's not controversial. Bring a linking post to the forums about the same, and its greater visibility had the reaction of uproar.

    How does a party besides maintainers/developers or the author gain the capability to declare a PR controversial?
     
  14. mkalash

    mkalash Donator

    They don't. The developers are trusted to see input and take the appropriate action. All you need to do is make your word known. And if enough people agree with your word, then the developer can move forward. Don't feel scorned if you're one or two who don't like a feature, but still don't see that controversial tag.

    And don't get started about not being able to trust staff.
     
    xales likes this.
  15. F-Tang Steve

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

    A PR would be controversial if there are enough negative comments. One person hating a PR and everyone else being ok with it doesn't make it controversial.
     
  16. StrategicImportance

    StrategicImportance Senior Enlisted Advisor

    Here's an example.

    In all honesty, if you frequent S&F, you should frequent GitHub, it's not exactly that massive of a feat.
     
  17. LorenLuke

    LorenLuke Commanding Officer

    My concern is less for myself and more for others within the community. Not being directly on forums or server may not be a massive block, but it still is an obstacle.

    Please don't preempt that which was never happening in the first place, it's condescending, rude, and, methinks, unwarranted.
     
  18. F-Tang Steve

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

    It does put up a thingy every time a PR is opened to the discord/IRC general chatter and coding channels. This means that even if you don't follow the github specifically you will still be exposed to stuff that opens while you're active.
     
  19. Lonefly

    Lonefly Donator

    Am against this for this reason. Sometimes I dislike something and I don't want to write an essay describing my feelings and emotions over it.

    Hell, sometimes I just think something is stupid as hell and that's about the extent that I'm willing to go with conversation.

    Also, getting rid of polls make me scream louder than a car with no muffler.
     
  20. F-Tang Steve

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

    You wouldn't need to write an essay, a single sentence would suffice.