Github Merging

Ask and discuss policy about game conduct and rules.

Moderators: In-Game Head Admins, In-Game Game Master

Forum rules
Read these board rules before posting or you'll get reprimanded.
Threads without replies for 30 days will be automatically locked.
Kenteko
 
Joined: Wed May 15, 2019 11:53 pm
Byond Username: Kenteko

Re: Github Merging

Postby Kenteko » Wed Jun 19, 2019 3:35 am #499393

Quick attempt at stating a potential policy:

If a certain level of dislikes is reached, as determined by the headmins, the pull request is blocked A poll must then be established wherein a certain percentage must be met in order for the PR to be merged.

The reason I say a certain % is so we do not have obstructive or obtuse polls that can be mired in double talk to help pass. The established numbers above would be prone to being changed by headmins.



User avatar
Screemonster
 
Joined: Sat Jul 26, 2014 7:23 pm
Byond Username: Scree

Re: Github Merging

Postby Screemonster » Wed Jun 19, 2019 3:55 am #499394

why should the headmins give a shit if a pr gets brigaded with downvotes by hippie and reddit

User avatar
oranges
Code Maintainer
 
Joined: Tue Apr 15, 2014 9:16 pm
Location: #CHATSHITGETBANGED
Byond Username: Optimumtact
Github Username: optimumtact

Re: Github Merging

Postby oranges » Wed Jun 19, 2019 4:05 am #499395

I am not willing to operate in an environment where popularity can stop a pull request.

If mso wants to introduce that I will resign and let someone else take over the headcoder role.

User avatar
Shadowflame909
 
Joined: Mon Jun 05, 2017 10:18 pm
Location: Think about something witty and pretend I put it here
Byond Username: Shadowflame909

Re: Github Merging

Postby Shadowflame909 » Wed Jun 19, 2019 4:09 am #499396

Because we can't make the maintainers give a shit.

Spoiler:
Image

ThanatosRa wrote:My biggest problem is that I can't fix any of this.


Boris wrote:shadowflame either has a brain the size of a pea or one the size of the moon and he's playing 58D chess.


BeeSting12 wrote:please write an apology to this forums, this community, the host, and the internet as a whole for the data storage space you wasted with this complaint.


BebeYoshi wrote:Saltyflame909


Cobby wrote:The trash bin... have you lost your way home anon?

User avatar
Timonk
 
Joined: Thu Nov 15, 2018 6:27 pm
Location: ur mum
Byond Username: Timonk

Re: Github Merging

Postby Timonk » Wed Jun 19, 2019 4:46 am #499398

Kenteko wrote:Quick attempt at stating a potential policy:

If a certain level of dislikes is reached, as determined by the headmins, the pull request is blocked A poll must then be established wherein a certain percentage must be met in order for the PR to be merged.


Thank you. As I am not a man of words myself, I appreciate this. Maybe a like/dislike ratio would be better than just dislikes?
Agux909 wrote:
Timonk wrote:This is why we make fun of Manuel


Woah bravo there sir, post of the month you saved the thread. I feel overwhelmed by the echo of unlimited wisdom and usefulness sprouting from you post. Every Manuel player now feels embarrased to exist because of your much NEEDED wise words, you sure teached'em all, you genius, IQ lord.




The hut has perished at my hands.
Image



The pink arrow is always right.

User avatar
Timonk
 
Joined: Thu Nov 15, 2018 6:27 pm
Location: ur mum
Byond Username: Timonk

Re: Github Merging

Postby Timonk » Wed Jun 19, 2019 4:47 am #499399

Shadowflame909 wrote:Because we can't make the maintainers give a shit.

That's what I want to achieve. Make them give a shit about likes/dislikes
Agux909 wrote:
Timonk wrote:This is why we make fun of Manuel


Woah bravo there sir, post of the month you saved the thread. I feel overwhelmed by the echo of unlimited wisdom and usefulness sprouting from you post. Every Manuel player now feels embarrased to exist because of your much NEEDED wise words, you sure teached'em all, you genius, IQ lord.




The hut has perished at my hands.
Image



The pink arrow is always right.

Kenteko
 
Joined: Wed May 15, 2019 11:53 pm
Byond Username: Kenteko

Re: Github Merging

Postby Kenteko » Wed Jun 19, 2019 4:57 am #499400

Timonk wrote:
Kenteko wrote:Quick attempt at stating a potential policy:

If a certain level of dislikes is reached, as determined by the headmins, the pull request is blocked A poll must then be established wherein a certain percentage must be met in order for the PR to be merged.


Thank you. As I am not a man of words myself, I appreciate this. Maybe a like/dislike ratio would be better than just dislikes?


I think a like/dislike ratio would work, absolutely.

User avatar
actioninja
Code Maintainer
 
Joined: Mon Jul 30, 2018 6:40 am
Location: comatose
Byond Username: Actioninja

Re: Github Merging

Postby actioninja » Wed Jun 19, 2019 8:24 am #499427

Seems like shadowflame is buttblasted as hell about unintended design consequences.
There has not been a rebalance/rework PR of mine merged that had major unintended design consequences. I was fully aware of every major ramification at the time of their merging, and nothing completely unexpected has arisen yet.
If there was anything "unintended" that results in something being "completely broken," it wasn't unintended, and is not a bug. It's a design choice you disagree with.
Image

Dr_bee
 
Joined: Fri Dec 23, 2016 6:31 pm
Byond Username: DrBee

Re: Github Merging

Postby Dr_bee » Wed Jun 19, 2019 8:25 am #499428

Kenteko wrote:
Timonk wrote:
Kenteko wrote:Quick attempt at stating a potential policy:

If a certain level of dislikes is reached, as determined by the headmins, the pull request is blocked A poll must then be established wherein a certain percentage must be met in order for the PR to be merged.


Thank you. As I am not a man of words myself, I appreciate this. Maybe a like/dislike ratio would be better than just dislikes?


I think a like/dislike ratio would work, absolutely.


To be honest I was mad about some of the changes oranges made, specifically the auto cloning change. However after the initial pain of the change I realized the reasons he laid out were right. Sometimes changes that are unpopular but done for good reason need to be done. It is also the nature of playing an open source constantly updated game for things like mechanics and balance to change, sometimes radically. which is another reason why I like ss13 in general.

TL;DR Nerfs suck but sometimes are needed, and design by popularity makes shitty products. there is a reason "design by committee" is considered a bad thing.

User avatar
Arianya
In-Game Game Master
 
Joined: Tue Nov 08, 2016 10:27 am
Byond Username: Arianya

Re: Github Merging

Postby Arianya » Wed Jun 19, 2019 9:39 am #499435

Kenteko wrote:Quick attempt at stating a potential policy:

If a certain level of dislikes is reached, as determined by the headmins, the pull request is blocked A poll must then be established wherein a certain percentage must be met in order for the PR to be merged.

The reason I say a certain % is so we do not have obstructive or obtuse polls that can be mired in double talk to help pass. The established numbers above would be prone to being changed by headmins.


a) Likes/dislikes on a PR are not really moderated or restricted in any way. There is obviously the potential for people with no relation to the codebase/server to brigade, and I'm not even considering downstreams in that.
b) "A certain level of dislikes determined by headmins" is so vague that it's useless. Would a headmin team with adversary feelings regarding the codebase be able to set the limit punishingly low to clog up the codebase waiting for polls?
c) "A certain percentage must be met in order for the PR to be merged" - A simple majority? A super majority? How does turnout factor in these things? How does this account for temporally unpopular changes that may yet be good for the game? Should a crash exploit be kept because a poll for it's fixing didn't reach simple majority?

This is without taking into account the autonomy this robs from coders, who are ultimately dedicating free time and effort to coding for the game. Given how divisive even new features can be, you'll have a chilling effect on coders wanting to implement new things if there's decent odds they'll end up embroiled in a week+ long poll during which they are a focal point of discussion.
Frequently playing as Aria Bollet on Bagil & Scary Terry

Source of avatar is here: https://i.imgur.com/hEkADo6.jpg

User avatar
Denton
Code Maintainer
 
Joined: Wed Aug 23, 2017 3:53 pm
Byond Username: Denton-30
Github Username: 81Denton

Re: Github Merging

Postby Denton » Wed Jun 19, 2019 10:26 am #499439

Kenteko wrote:
Timonk wrote:
Kenteko wrote:Quick attempt at stating a potential policy:

If a certain level of dislikes is reached, as determined by the headmins, the pull request is blocked A poll must then be established wherein a certain percentage must be met in order for the PR to be merged.


Thank you. As I am not a man of words myself, I appreciate this. Maybe a like/dislike ratio would be better than just dislikes?


I think a like/dislike ratio would work, absolutely.

Making PR merging dependant on upvotes/downvotes wouldn't work for many reasons. The most obvious one is that reddit and hippie would brigade PRs just to fuck with the server.

Popularity also doesn't mean that a change is good or bad for the game. For example take the removal of circuits, which (while fun to use) were a complete shitshow balance and code wise.
Image

Kenteko
 
Joined: Wed May 15, 2019 11:53 pm
Byond Username: Kenteko

Re: Github Merging

Postby Kenteko » Wed Jun 19, 2019 4:04 pm #499473

Arianya wrote:
a) Likes/dislikes on a PR are not really moderated or restricted in any way. There is obviously the potential for people with no relation to the codebase/server to brigade, and I'm not even considering downstreams in that.
b) "A certain level of dislikes determined by headmins" is so vague that it's useless. Would a headmin team with adversary feelings regarding the codebase be able to set the limit punishingly low to clog up the codebase waiting for polls?
c) "A certain percentage must be met in order for the PR to be merged" - A simple majority? A super majority? How does turnout factor in these things? How does this account for temporally unpopular changes that may yet be good for the game? Should a crash exploit be kept because a poll for it's fixing didn't reach simple majority?

This is without taking into account the autonomy this robs from coders, who are ultimately dedicating free time and effort to coding for the game. Given how divisive even new features can be, you'll have a chilling effect on coders wanting to implement new things if there's decent odds they'll end up embroiled in a week+ long poll during which they are a focal point of discussion.


These are very good points and I'll try and address each.
A) Brigading constantly enough that it has a noticeable effect takes work and at some point, will stop. When this policy is first instituted, we'll probably see a rash of haters show up and mass downvote. This is not even account for potential botting or the like. While this trend is something to easily notice and ban, a potential amendment is as follows: When the issue of something being contentious is brought to the headmins attention, they make a judgment call about whether this is in the scope of a community poll or not. Most will get yay'd pretty much instantly due to headmins realizing some merges are harmless, but they will absolutely take notice of the big ones.
B) Yes, absolutely. Headmins can run on coder autonomy which will be something the community decides upon, due to whether or not they receive the vote. The truth is that the headmins, in doing this, will be putting much more work on themselves and it's very likely that we'll see more setting it high versus low.
C) Another good point. For one, anything on the issues tracker (which is to say a bug or a crash exploit) would be pushed through without opposition. Fixing bugs and exploits are things that most people want, if not everyone, and this is not a question of coder oversight (we have tags for this too). As for temporarily unpopular changes, it is likely that when something goes to poll, a headmin will also be likely to give a go ahead test merge it so that people can see or feels how it is then vote after. This will make better use of test merges and, part of the voting could be a Yay, Nay, or Longer Test Merge.

As far as it robbing autonomy from coders, cest la vie. If a coder is put under the same scrutiny as others are for their actions of contribution, that sounds like a good thing to me. It stops shitcode from going through and will have coders be tested on what does or does not work. Why is it that we would put Okand and Kilo under massively extensive scrutiny but not coders that provide features? Saying "a map is different" is a non starter because major features or things that will be hit by this level of scrutiny are on that same level. Right now, SOME moderation is better than NO moderation, and it's very easy for a maintainer to shut down something a coder is working on because they don't like the cut of their gib or they demand the coder do something above and beyond what their PR is doing.

Denton wrote:Making PR merging dependant on upvotes/downvotes wouldn't work for many reasons. The most obvious one is that reddit and hippie would brigade PRs just to fuck with the server.

Popularity also doesn't mean that a change is good or bad for the game. For example take the removal of circuits, which (while fun to use) were a complete shitshow balance and code wise.


As mentioned above, brigades take effort and time and, while many people absolutely will show up and troll on the first week this policy comes into effect, you will see falloff as idiots and trolls get bored. Over a long enough timeline, the entire community will start to see and notice what is or is not contentious and headmins will likely adjust accordingly to tweak the numbers. No plan survives first contact and the policy is built to be flexible enough to allow for that adjustment.

As for popularity and game design, this is a bit false starter. Many players have no real clue what they want, and this is highly documented in both marketing and games. That being said, many players DO know when some change or concept would impact their fun or their job, especially if it's something they're doing actively. Someone who plays a substantial amount of viro will be more aware of the implications from viro change than someone who has never touched the thing. The former will likely raise a bigger ruckus and work to draw some level of support to their views which, in turn, may lead to brigading in a way that may work. Most community members won't care enough about small changes to do this.

The second part of the statement is likewise a bit of a false dichotomy. Circuits were a shitshow balance and probably an entire bit of spaghetti code all around. You know what also is? Exosuits. As a matter of fact, if we get down to a lot of things that fall into that, we'll find that we have a lot of those shitshow balance/code features in the code that people just accept (Ninjas and Stealth Implant come to mind). The point I'm trying to make is that these are likely excuses to remove popular features that an individual coder/maintainer is biased against or dislikes, not for the purpose of cleaning up code and game design. That being said, a compromise for this could simply be to make it so that once a headmin 1) Acknowledges it's a community issue and 2) Creates a poll, they can push for a test merge for the duration of the poll to let the community truly test it. As mentioned above, if the poll is simple enough (yay/nay/test merge longer), the community is granted the power to discover for themselves whether it's as dangerous as some people believe. If a poll runs for a week or so, players can and will acclimate within that period and come to a decision by week's end in alignment with their own view on it. We've seen this happen with some people on stasis beds after that short of a time period.

To be clear, all of this is to bring more scrutiny and accountability to maintainers. Most coders will very likely be wholly unaffected by this because small or individual changes will go through, sight unseen. It's very likely that the real big ones (removals and reworks) will be the ones to hit the wall of public opinion. If anything, this will promote more design documents and sales pitches from coders who want to get their idea seen and critiqued, as people will likely trust those who put in enough work to show the public they care. It also puts the opus on maintainers to stop pushing shitcode or their own pet projects through as people will likely start to raise a ruckus when these things happen with no recourse. Plus, it forces maintainers to be more diplomatic because as soon as one goes "lol fuk u i do wat i want" they're going to get vote bombed to hell and back. This is a good thing in my book.

Muncher21
 
Joined: Tue Apr 25, 2017 2:53 pm
Byond Username: Muncher21

Re: Github Merging

Postby Muncher21 » Wed Jun 19, 2019 5:15 pm #499495

Anyone arguing for PR's to be managed by popular vote should read this.

Just because people dislike a change doesn't mean it's bad.

User avatar
Shadowflame909
 
Joined: Mon Jun 05, 2017 10:18 pm
Location: Think about something witty and pretend I put it here
Byond Username: Shadowflame909

Re: Github Merging

Postby Shadowflame909 » Wed Jun 19, 2019 5:29 pm #499498

Players are clearly dissatisfied with something in this process.

I don't think "No change. everything is fine" Will ease the growing dissatisfaction of the community.

I mean, if you felt like you were subjected to the whims of someone else with no input. You'd get annoyed pretty fast if it became detrimental to you.

As a wise man once put it. A fed human doesn't revolt.

So certainly, you can be a leader. You can truly bring the people in the right direction. But growing the flames of dissatisfaction is doing no-one any favors.

Send help.

Spoiler:
Image

ThanatosRa wrote:My biggest problem is that I can't fix any of this.


Boris wrote:shadowflame either has a brain the size of a pea or one the size of the moon and he's playing 58D chess.


BeeSting12 wrote:please write an apology to this forums, this community, the host, and the internet as a whole for the data storage space you wasted with this complaint.


BebeYoshi wrote:Saltyflame909


Cobby wrote:The trash bin... have you lost your way home anon?

Kenteko
 
Joined: Wed May 15, 2019 11:53 pm
Byond Username: Kenteko

Re: Github Merging

Postby Kenteko » Wed Jun 19, 2019 5:40 pm #499499

Muncher21 wrote:Anyone arguing for PR's to be managed by popular vote should read this.

Just because people dislike a change doesn't mean it's bad.


https://en.wikipedia.org/wiki/Argument_from_authority Just because Oranges/a maintainer says something is good, doesn't make it good.

The point of adding the community into the mix is not to suddenly make this a democratic utopia that will have all the trains run on time and make everything popular choice, it's to add accountability. Maintainers literally push whatever they want, whenever they want, with next to no repercussions. Their accountability is zero or approaching zero. It is to the point where Oranges can and often does mock and insult people who have a PR he disagrees with. On top of this, there have been several examples of maintainers asking people who make small PRs to do massive effective code overhauls because they can. "Out of scope" only matters when a maintainer is put on the spot, such as when Oranges is asked to write a bare bones/simplistic design document to help guide code creation.

This is effectively community discontent reaching a boiling point; people are getting fed up that what they have had fun with is getting removed without any input whatsoever or even care about the community. If we take null crates removal as an example, it makes sense from a design and policy perspective to remove it because it leads to potential rule breaking. This situation is something that the community likely should be included in because letting it go through acknowledges to those above that they would rather remove rule breaking potential while stopping the merge means that they are fine with the implications therein and may instead prefer harsher enforcement.

But for right now? Community members just have to deal with it. Many are by raging, others are by just leaving. Both of the situations cause the community to deteriorate and, as has been proven in almost every single MMO on the planet, when friends start to leave, other friends leave to. This isn't a doom and gloom or apocalypse situation, but having worsened servers/people leaving is not something anyone should work to.

Muncher21
 
Joined: Tue Apr 25, 2017 2:53 pm
Byond Username: Muncher21

Re: Github Merging

Postby Muncher21 » Wed Jun 19, 2019 6:23 pm #499504

Kenteko wrote:This situation is something that the community likely should be included in because letting it go through acknowledges to those above that they would rather remove rule breaking potential while stopping the merge means that they are fine with the implications therein and may instead prefer harsher enforcement.

I completely disagree. Players will always opt to keep their toys, not matter how round breaking or disruptive they are. If they had the option they'll always want to load more work onto the admins and coders, while doing nothing themselves. This is especially true because the playerbase has no idea how much work something like coding a new features, testing every single edge-case, or moderating a server really is. This is the exact time an experienced maintainer needs to say "This is the right decision even if you don't like it" and push the PR through anyways.

Kenteko
 
Joined: Wed May 15, 2019 11:53 pm
Byond Username: Kenteko

Re: Github Merging

Postby Kenteko » Wed Jun 19, 2019 6:39 pm #499507

Muncher21 wrote:
Kenteko wrote:This situation is something that the community likely should be included in because letting it go through acknowledges to those above that they would rather remove rule breaking potential while stopping the merge means that they are fine with the implications therein and may instead prefer harsher enforcement.

I completely disagree. Players will always opt to keep their toys, not matter how round breaking or disruptive they are. If they had the option they'll always want to load more work onto the admins and coders, while doing nothing themselves. This is especially true because the playerbase has no idea how much work something like coding a new features, testing every single edge-case, or moderating a server really is. This is the exact time an experienced maintainer needs to say "This is the right decision even if you don't like it" and push the PR through anyways.


This is markedly untrue, the community has wanted stuff removed plenty. Donut Station is by and far one of the best examples of this. Likewise, there's plenty of things that the community does not care about that would get pushed through without a problem. Sec borgs are arguably another example because even talking about them brings such unrestrained vitriol.

What this policy does is put the opus on the coders to convince the community the change is good. If and when a policy is brought up as an issue, the coder will now have to assemble reasons as to why they should be pushed through. Convincing people and test merging will, in turn, help their case and allow those who wish to oppose it or talk about it have a forum to do so.

Plus, if you look at some recent changes, the community was behind a handful of nerfs and changes. The Russian Surplus Nerf comes to mind and the Stun Combat change was as well. Even the most recent removal, Spiders from Xeno, had ridiculously large support behind it. There will be complainers no matter what, but what needs to be stressed is that the headmins will determine when the critical mass is met.

Coders and maintainers are people too, and putting them on a pedestal for being brave and pushing garbage through does them no favors. Let me give you an example: The maintainers believe that all non SM engine types should be removed. This is fine from a concept and, especially when dealing with tesla, you can talk about how tesla is damaging to frame rate. So far so good. However, when this change was pushed to Pubby and Donut, it was done in such a slipshod manner that it made those stations either unplayable or the engine delamming near instantly. It also removed what made Donut station special (the singulo) and this could be something that the community would probably like to comment on.

It's alright to disagree with a coder/maintainer's design choices. What this policy does is push SOME accountability onto the coders to stop abusing things. Realistically, I'd also like to propose a rollback policy as well that ties into this, but that may beyond the scope of this thread.

Edit: Added spider removal because I just remembered.

Muncher21
 
Joined: Tue Apr 25, 2017 2:53 pm
Byond Username: Muncher21

Re: Github Merging

Postby Muncher21 » Wed Jun 19, 2019 6:52 pm #499510

Kenteko wrote:This is markedly untrue, the community has wanted stuff removed plenty. Donut Station is by and far one of the best examples of this. Likewise, there's plenty of things that the community does not care about that would get pushed through without a problem. Sec borgs are arguably another example because even talking about them brings such unrestrained vitriol.

A feature players like (nullcrates/circuits) is not the same as a feature players dislike (Sec borgs/donut). Players will never be ok with "fun" features being removed. This is not a valid analogy.

Kenteko wrote:What this policy does is put the opus on the coders to convince the community the change is good. If and when a policy is brought up as an issue, the coder will now have to assemble reasons as to why they should be pushed through.

Then the players stick their fingers in their ears an completely ignore valid reasons to remove "fun" features. See circuits. See null crates.

Kenteko wrote:Coders and maintainers are people too, and putting them on a pedestal for being brave and pushing garbage through does them no favors.

Saying that coders and admins have a deeper understand of the effort required to run and maintain a codebase is not "putting them on a pedestal". It's acknowledging that through experience some people have a better perspective on what is needed to fix issues, and why some solutions will and will not work. I would not tell an electrician that my opinion on how to wire and maintain my house's power is just as valid as his.

Kenteko
 
Joined: Wed May 15, 2019 11:53 pm
Byond Username: Kenteko

Re: Github Merging

Postby Kenteko » Wed Jun 19, 2019 7:26 pm #499522

Muncher21 wrote:A feature players like (nullcrates/circuits) is not the same as a feature players dislike (Sec borgs/donut). Players will never be ok with "fun" features being removed. This is not a valid analogy.

Have you ever considered that maybe removal was not the solution? Compromises could be make, balance changes are iterative, and actual game design issues and problems could be discussed. Removing things without talking about it just makes it the only solution.

Muncher21 wrote:Then the players stick their fingers in their ears an completely ignore valid reasons to remove "fun" features. See circuits. See null crates.

Other servers have somehow found to make both work. As a matter of fact, integrated circuitry has been fixed by people who chose to do the actual balance part and not just remove things. There's even a request to bring them back viewtopic.php?f=9&t=22419

Muncher21 wrote:Saying that coders and admins have a deeper understand of the effort required to run and maintain a codebase is not "putting them on a pedestal". It's acknowledging that through experience some people have a better perspective on what is needed to fix issues, and why some solutions will and will not work. I would not tell an electrician that my opinion on how to wire and maintain my house's power is just as valid as his.


Coders are knowledgeable about code. As someone who has been trained in game design, and has done extensive research on it, it requires a completely different mindset than coding. Likewise, administrative work requires different skills and mindsets than game design. That's not to say they exist in their own isolated island, but the mindsets required are different. Game design is about massive iteration and experimentation, particularly with an active community. This is why test builds and play tests are so important and why iterative design is important for system work.

The current maintainers don't give a damn about any of that.

If they did, we wouldn't see mass removals on some tools that are very easily iterated on. We wouldn't see creations that are an insult to people who enjoyed the original (Peacekeeper Borg) or a refusal to even address small changes. In my opinion, the current maintainers knowledge of game design is either flawed or just bad because of their stark refusal to iterate and the hostility they approach the community with. The worst part about this is how many forks and downstreams are gaining massive traction because many of those tend to do actual game design, iterate, and balance things as appropriate.

Do not confuse coders and programmers for game and system designers. There is crossover and there are people who can make it work, but the two jobs are only related in one figures out what the system is and the other makes it work.

User avatar
WarbossLincoln
 
Joined: Wed Feb 10, 2016 11:14 pm
Byond Username: WarbossLincoln

Re: Github Merging

Postby WarbossLincoln » Wed Jun 19, 2019 7:50 pm #499532

In any kind of software development environment someone at the end of the day has to be in charge of accepting code changes. It's nice to imagine everyone having a say but it's not going to work out well. IRL I talk about my code and implementation with my co workers, get their ideas, and work with them to come up with the best way we can think of to solve a problem or add a feature. But our boss is the one who decides if that's going to fly or not.

In a business you would have stakeholders and POs who the head coder answers to because there's money on the line. Here where there isn't a product or profit it's just the head coder.

tldr; you're not going to get democracy in a codebase. Someone has to be in charge or you just have chaos.

The best way for you, the player, to have an impact on the code is to either A: start coding yourself, talk about your ideas and features with oranges to get his input, submit a PR. Or B: submit coherent, detailed, and specific ideas on features and changes you would like to see. With specific details about mechanics, reasons why it's good(or bad for removal), and be prepared have some back and forth with a developer if they like your idea to refine it.
--Crocodillo

Image

User avatar
Denton
Code Maintainer
 
Joined: Wed Aug 23, 2017 3:53 pm
Byond Username: Denton-30
Github Username: 81Denton

Re: Github Merging

Postby Denton » Wed Jun 19, 2019 8:09 pm #499539

Kenteko wrote:As mentioned above, brigades take effort and time and, while many people absolutely will show up and troll on the first week this policy comes into effect, you will see falloff as idiots and trolls get bored. Over a long enough timeline, the entire community will start to see and notice what is or is not contentious and headmins will likely adjust accordingly to tweak the numbers. No plan survives first contact and the policy is built to be flexible enough to allow for that adjustment.

You severely underestimate the condensed autism of this community and the r*ddit shaped tumors attached to it. Just look at the the recent pronouns PR for an example, people came flocking from every single community to post 300 shitposts and personal attacks.
Most players are cool and provide valuable feedback, but that doesn't mean that there wouldn't be constant brigading.

As for popularity and game design, this is a bit false starter. Many players have no real clue what they want, and this is highly documented in both marketing and games. That being said, many players DO know when some change or concept would impact their fun or their job, especially if it's something they're doing actively. Someone who plays a substantial amount of viro will be more aware of the implications from viro change than someone who has never touched the thing. The former will likely raise a bigger ruckus and work to draw some level of support to their views which, in turn, may lead to brigading in a way that may work. Most community members won't care enough about small changes to do this.

Nobody is going to willingly give up their fun toys. Look at techwebs, RnD mains HATED it because it no longer made them the gatekeeper of eguns and BoHs.
Similarly, botany players hated the removal of separated chemicals and cargo players hated the removal of null crates.
If a feature is fun for a subset of players but awful for the game overall, they still won't want to see it gone.
Image

User avatar
Timonk
 
Joined: Thu Nov 15, 2018 6:27 pm
Location: ur mum
Byond Username: Timonk

Re: Github Merging

Postby Timonk » Wed Jun 19, 2019 8:24 pm #499547

I mean, I have always known the tech web that it is today. How was it before that?


Also maybe the like/dislike could be given a restriction. Something like you need to have 5 merged PRs before you can vote?
Agux909 wrote:
Timonk wrote:This is why we make fun of Manuel


Woah bravo there sir, post of the month you saved the thread. I feel overwhelmed by the echo of unlimited wisdom and usefulness sprouting from you post. Every Manuel player now feels embarrased to exist because of your much NEEDED wise words, you sure teached'em all, you genius, IQ lord.




The hut has perished at my hands.
Image



The pink arrow is always right.

User avatar
imsxz
In-Game Admin
 
Joined: Sat Dec 16, 2017 4:27 pm
Byond Username: Imsxz

Re: Github Merging

Postby imsxz » Wed Jun 19, 2019 8:33 pm #499548

Timonk wrote:I mean, I have always known the tech web that it is today. How was it before that?


Also maybe the like/dislike could be given a restriction. Something like you need to have 5 merged PRs before you can vote?


assuming mats arent a worry you could have old rnd maxed in like 10 mins and sci spawned with omnilathe and there was no ore silo so you had to go to the ORM and vend all the mats before someone else does
Image

please subscribe to me on youtube

terranaut wrote:i saw this video before it was posted here
you too can be cool like me if you just subscribe to imsxz youtube channel :shades:



Arianya wrote:no, not the snails, shut up imsxz


Nervore wrote:I am going to will you out of existence, Imsxz.
One day, you will just cease to exist.


Image

Kenteko
 
Joined: Wed May 15, 2019 11:53 pm
Byond Username: Kenteko

Re: Github Merging

Postby Kenteko » Wed Jun 19, 2019 9:00 pm #499554

WarbossLincoln wrote:In any kind of software development environment someone at the end of the day has to be in charge of accepting code changes. It's nice to imagine everyone having a say but it's not going to work out well. IRL I talk about my code and implementation with my co workers, get their ideas, and work with them to come up with the best way we can think of to solve a problem or add a feature. But our boss is the one who decides if that's going to fly or not.

In a business you would have stakeholders and POs who the head coder answers to because there's money on the line. Here where there isn't a product or profit it's just the head coder.

tldr; you're not going to get democracy in a codebase. Someone has to be in charge or you just have chaos.

The best way for you, the player, to have an impact on the code is to either A: start coding yourself, talk about your ideas and features with oranges to get his input, submit a PR. Or B: submit coherent, detailed, and specific ideas on features and changes you would like to see. With specific details about mechanics, reasons why it's good(or bad for removal), and be prepared have some back and forth with a developer if they like your idea to refine it.


Your boss has accountability to their boss, who has accountability up the line until the process hits deployment or some level of end user. If your code ends up being garbage and your boss green lights it, there's a chance he'll get in trouble before you (though you will likely also get in trouble).

We have nothing like that in the current system. As long as maintainers break no obvious massive rules, they can do whatever they want, how they want, with no repercussions. Sure, the server will suffer as people leave, but the maintainers can and will deflect that immediately (and have) and blame someone else. Eventually, the situation breaks apart and the server collapses. We absolutely have the power of popularity and continuity, but that's not an absolute.

Denton wrote:You severely underestimate the condensed autism of this community and the r*ddit shaped tumors attached to it. Just look at the the recent pronouns PR for an example, people came flocking from every single community to post 300 shitposts and personal attacks.
Most players are cool and provide valuable feedback, but that doesn't mean that there wouldn't be constant brigading.


So here's the thing, if you look at the vast majority of the pulls, most of the ones that do get merged do so with little to no comments or issue. You absolutely should bring up the pronoun PR because here's how it would likely play out:
1) Headmins are called on the fact that this has reached critical mass.
2) Headmins evaluate it. They realize that this is both a policy problem and a simple rules acknowledgement of the code being used to augment it. Maybe they don't.
3) New Headmin policy to stop being a mouth breathing assclown against LGBT people is brought in and the code is merged.
3a) Headmins are divided and brought to a poll. There is now an intense policy discussion between people who want equality and those who don't. This may ruin a Headmin's tenure or may cause people to leave. The poll gives us the result of what the community wants.

Both of those situations create conversation and help establish culture. It's often said that racism is part of TG. Now, discrimination is front and center and the headmins must take a stance. This creates precedent and causes ACTUAL REPERCUSSIONS to further shape the culture. I don't know about you, but I feel like this is an important process.

Denton wrote:Nobody is going to willingly give up their fun toys. Look at techwebs, RnD mains HATED it because it no longer made them the gatekeeper of eguns and BoHs.
Similarly, botany players hated the removal of separated chemicals and cargo players hated the removal of null crates.
If a feature is fun for a subset of players but awful for the game overall, they still won't want to see it gone.


False equivalence. Techwebs was a redistribution of wealth not a stark removal. Objects were placed into proper departments. On top of it, the omnilathe still exists (and has multiple sources and locations including a guarantee). Meanwhile, looking at separated chemicals removal, there was clear conversation and discourse about it, including bringing in someone who was versed in botany enough to explore it. If your argument is that one department and one set of mains hates removal, that's not big enough of a playing group to merit a blip. It wouldn't even get on the radar with this policy. I'll give you the counterpoint I used earlier: Xeno players were mad at losing headslugs, xenos, and nurse spiders. The rest of the community wanted it gone. It's easy to cherry pick situations that people got upset singularly, but most of the community got incredibly upset over the loss of sleepers, not just medbay. I'd argue more than a few people were upset over the loss of Null Crates, too.

Even better, let's talk about something that just went through of "players losing their toys" that everyone wanted rebalanced: Mechs and rocket launchers. By the logic presented here, the entire community would be against this. Spoiler alert: They're not.

And you know what? Knowing how to code doesn't matter when a maintainer can flat out block you because they feel like it. Alternatively, asking someone to make a change massively out of scope for it. This policy would not address this, as it is outside the realm of community pushing PRs through, and is instead trying to address maintainers/coders having no repercussion and pushing what they want.

SpaceManiac
Code Maintainer
 
Joined: Fri Sep 22, 2017 4:06 am
Byond Username: SpaceManiac
Github Username: SpaceManiac

Re: Github Merging

Postby SpaceManiac » Wed Jun 19, 2019 9:03 pm #499555

Circuit code was a lot worse than exosuit code and the idea that the poor quality was an "excuse" because an anonymous maintainer had a grudge against the feature is laughable. Circuit code was not removed for being "messy". It was removed for being full of exploits and balance issues that nobody was volunteering to fix for a month or more. The people who knew about the exploits weren't even telling the maintainers what they were. The only viable option was to remove the feature.

Maps are different. A single map is a much larger maintenance burden than almost any single feature because any future change which might involve remapping is now more mapping work than before. Mapping is already a lot of work compared to coding without this problem. This is from experience with techwebs, both adding and removing circuits, and with the nanomachine labs. Maps need to be good enough to replace an existing map. More different content is more good for the game. It's also more work to maintain, and we can't afford to create that work for ourselves.

Donut's singularity was replaced with the SM by the author of Donut without an explicit request from maintainers because "In every round I hopped on to observe and take feedback over the past months, almost every time it ended in the singularity being released and a shuttle call within 25 minutes". Its distinctiveness was not enough to justify its problems. There's an argument to be made that it was merged too hastily, but keep in mind that the same maintainer who merged it was the one who put in all the work to fix it.

I don't understand this argument that maintainers somehow have too much discretion to reject features they don't like but also not enough discretion to reject code that isn't tested enough. Striking the balance between "demanding above and beyond" of contributors and making sure that their code is good before it goes in is one of the challenges of the maintainership job.

Coding is volunteer work and you will never be able to compel a contributor to make a change that they themselves don't care about without paying them. Maintainership is also volunteer work and it has vastly more to do with reviewing PRs for maintainability and putting out fires than with gatekeeping game balance.

Kenteko
 
Joined: Wed May 15, 2019 11:53 pm
Byond Username: Kenteko

Re: Github Merging

Postby Kenteko » Wed Jun 19, 2019 9:42 pm #499578

SpaceManiac wrote:Circuit code was a lot worse than exosuit code and the idea that the poor quality was an "excuse" because an anonymous maintainer had a grudge against the feature is laughable. Circuit code was not removed for being "messy". It was removed for being full of exploits and balance issues that nobody was volunteering to fix for a month or more. The people who knew about the exploits weren't even telling the maintainers what they were. The only viable option was to remove the feature.


If this is true, and I have no reason to believe it's not, then the actual amount of people who would have complained would have been a vocal minority. It may have even been removed with intent to fix, and the community would likely have been more understanding.

SpaceManiac wrote:Maps are different. A single map is a much larger maintenance burden than almost any single feature because any future change which might involve remapping is now more mapping work than before. Mapping is already a lot of work compared to coding without this problem. This is from experience with techwebs, both adding and removing circuits, and with the nanomachine labs. Maps need to be good enough to replace an existing map. More different content is more good for the game. It's also more work to maintain, and we can't afford to create that work for ourselves.


Why? Why are we only limited to five maps? When Kilo was test merged, Sybil somehow managed to operate without exploding into flames for having six maps. On top of that, the maintainer who works on Delta also worked on Kilo. I should point out that many of the big features need some maintainers as well, and odds are good those are mostly forgotten.

SpaceManiac wrote:Donut's singularity was replaced with the SM by the author of Donut without an explicit request from maintainers because "In every round I hopped on to observe and take feedback over the past months, almost every time it ended in the singularity being released and a shuttle call within 25 minutes". Its distinctiveness was not enough to justify its problems. There's an argument to be made that it was merged too hastily, but keep in mind that the same maintainer who merged it was the one who put in all the work to fix it.


This is dynamic/organic design. Donut's goal changed and, to be honest, became a meme map that has singulo that was almost guaranteed to loose became a meme. Who would have thought. If the community was happy of where it went, then the situation has changed and weaker design has become positive design. Donut, to the community, was a short chaotic map. We see this happen all the time with examples I've stated previously in thread (combos for fighting games, wavedashing for SSBB) and some times, this causes massive schism when they're removed. Hell, we can probably see this happening right now if the stealth implant bug is "fixed" and people get angry over. Maybe the goal there would be to change the bug to the new standard.

SpaceManiac wrote:I don't understand this argument that maintainers somehow have too much discretion to reject features they don't like but also not enough discretion to reject code that isn't tested enough. Striking the balance between "demanding above and beyond" of contributors and making sure that their code is good before it goes in is one of the challenges of the maintainership job.

Coding is volunteer work and you will never be able to compel a contributor to make a change that they themselves don't care about without paying them. Maintainership is also volunteer work and it has vastly more to do with reviewing PRs for maintainability and putting out fires than with gatekeeping game balance.


So once again I'll say that they're not working for free and once again I'll echo that prestige and a platform are a reward for working, as well as creating a game people enjoy. Putting in accountability and duties to people volunteering would simply make people cuplable for their job and if nothing else promote better designs and coding. Shitcode that gets through, and some decent amount has gotten through, simply lessens the codebase as a whole and creates a rising pile of shit that is ignored. We have reached the point where maintainers and coders have soured the community so badly that strife is happening and it's starting to echo loud enough that some people are quitting. You can also argue that some of the people producing the shitcode are ignored due to favoritism, nepotism, or straight up apathy.

To give an example, a coder made a pull to make a sec hud meson. In a great way of ignoring out of scope, someone threatened to close it unless that person, who made one pair of glasses, would completely rewrite all the various glasses and then some. Needless to say, it got closed. Nice way to promote people who try to code and are then thrown a giant pile of crap to refactor instead of just letting their innocent PR through. So where's the reasoning going from there?

User avatar
oranges
Code Maintainer
 
Joined: Tue Apr 15, 2014 9:16 pm
Location: #CHATSHITGETBANGED
Byond Username: Optimumtact
Github Username: optimumtact

Re: Github Merging

Postby oranges » Wed Jun 19, 2019 9:58 pm #499585

With all due respect you clearly have no idea about just how bad this playerbase is with changes

User avatar
oranges
Code Maintainer
 
Joined: Tue Apr 15, 2014 9:16 pm
Location: #CHATSHITGETBANGED
Byond Username: Optimumtact
Github Username: optimumtact

Re: Github Merging

Postby oranges » Wed Jun 19, 2019 10:07 pm #499590

Why? Why are we only limited to five maps? When Kilo was test merged, Sybil somehow managed to operate without exploding into flames for having six maps. On top of that, the maintainer who works on Delta also worked on Kilo. I should point out that many of the big features need some maintainers as well, and odds are good those are mostly forgotten.

The issue with having too many maps is because it means if you want to make a major overhaul you have to make the same mapping changes on every single map. That massively, massively hurts feature velocity because mapping is a real pain in the ass and only a few people want to do it.

User avatar
Arianya
In-Game Game Master
 
Joined: Tue Nov 08, 2016 10:27 am
Byond Username: Arianya

Re: Github Merging

Postby Arianya » Wed Jun 19, 2019 10:44 pm #499611

re: Headmins in charge of codebase (I'm paraphrasing but this is what I've mainly taken away from this discusssion) - Headmins already have enough workload and headaches being just in charge of the administration. Adding every code controversy, small or large, to their plate would just enhance burnout and slow the codebase to a crawl if discussion or thought is needed on the headmin's part.

That's without getting into the problematic populism that's bred when you give headmins control over the code and they have to court votes to win - even without headmins having much influence on code we had the likes of goofball trying to bribe voters with coding favours - something that would quickly become beyond aggravating to a headcoder or maintainers when they're being jerked around by whatever arbitrary promises a headmin candidate may have made.
Frequently playing as Aria Bollet on Bagil & Scary Terry

Source of avatar is here: https://i.imgur.com/hEkADo6.jpg

Kenteko
 
Joined: Wed May 15, 2019 11:53 pm
Byond Username: Kenteko

Re: Github Merging

Postby Kenteko » Wed Jun 19, 2019 10:59 pm #499623

Arianya wrote:re: Headmins in charge of codebase (I'm paraphrasing but this is what I've mainly taken away from this discusssion) - Headmins already have enough workload and headaches being just in charge of the administration. Adding every code controversy, small or large, to their plate would just enhance burnout and slow the codebase to a crawl if discussion or thought is needed on the headmin's part.

That's without getting into the problematic populism that's bred when you give headmins control over the code and they have to court votes to win - even without headmins having much influence on code we had the likes of goofball trying to bribe voters with coding favours - something that would quickly become beyond aggravating to a headcoder or maintainers when they're being jerked around by whatever arbitrary promises a headmin candidate may have made.


Valid points, but at this point I'd request an alternative. If Headmins have a hard time with it, then maybe add a method to make it feasible. It would slow the codebase, but not extensively, at least when it comes to big changes like stasis beds.

I also want to point out that this would not give headmins control, it would give the community a stopgap. Headmins cannot directly shut down a PR, instead moving the process into the community's hands at which point the coder or maintainer or what have you has to convince others of their measures. The entire direct response of this is akin to reviewing a complaint thread and, with proper practice and efficiency, can probably be knocked out in batches. Maintainers/Coders can report when a PR has reached critical mass and the batches are then ruled upon all in one an hour a week. Historically looking at PRs, we're talking about maybe one PR that is merged every two weeks just on the history of merged PRs. Remember: This still has to pass standard muster.

oranges wrote:With all due respect you clearly have no idea about just how bad this playerbase is with changes


I know my history and as I have mentioned, this is a trend trackable on any game large enough to merit worth. Literally every MMO has experienced this situation and, if you track and follow them throughout the years, you see a stalwart movement towards community interaction and extensive testing schedules for confirmation. Many people have actually attributed WoW's current crisis to a lack of this, on top of slipping schedule work. TG is not unique or new in handling difficult audiences, the difference is for any other circumstance, money is on the line. Hell, business classes are taught about the disastrous effects the NGE brought SWG and how alienating your community can bankrupt you.

So no, I'm very aware of how bad the player base is with changes because this is a historic problem with quantifiable data across the history of game design. You will find, historically, that people are more likely to respond positively when you at least make it seem like you're listening to them. That is what this policy endeavors to change as a start.

User avatar
actioninja
Code Maintainer
 
Joined: Mon Jul 30, 2018 6:40 am
Location: comatose
Byond Username: Actioninja

Re: Github Merging

Postby actioninja » Wed Jun 19, 2019 11:13 pm #499628

This is a historic problem among game dev that the generally agreed upon solution is to tell players to fuck off because they don't know what the hell they're talking about.
That large companies want to have good PR is a completely different matter.
Image

User avatar
Shadowflame909
 
Joined: Mon Jun 05, 2017 10:18 pm
Location: Think about something witty and pretend I put it here
Byond Username: Shadowflame909

Re: Github Merging

Postby Shadowflame909 » Wed Jun 19, 2019 11:18 pm #499631

oranges wrote:
Why? Why are we only limited to five maps? When Kilo was test merged, Sybil somehow managed to operate without exploding into flames for having six maps. On top of that, the maintainer who works on Delta also worked on Kilo. I should point out that many of the big features need some maintainers as well, and odds are good those are mostly forgotten.

The issue with having too many maps is because it means if you want to make a major overhaul you have to make the same mapping changes on every single map. That massively, massively hurts feature velocity because mapping is a real pain in the ass and only a few people want to do it.


I think we should just do a massive vote for 1 map in the rotation.

Map battle royale.

Spoiler:
Image

ThanatosRa wrote:My biggest problem is that I can't fix any of this.


Boris wrote:shadowflame either has a brain the size of a pea or one the size of the moon and he's playing 58D chess.


BeeSting12 wrote:please write an apology to this forums, this community, the host, and the internet as a whole for the data storage space you wasted with this complaint.


BebeYoshi wrote:Saltyflame909


Cobby wrote:The trash bin... have you lost your way home anon?

User avatar
Mickyan
Github User
 
Joined: Tue Oct 14, 2014 11:59 pm
Byond Username: Mickyan
Github Username: Mickyan

Re: Github Merging

Postby Mickyan » Wed Jun 19, 2019 11:20 pm #499632

Your analogy is pointless because tgstation isn't a commercial product and coders aren't employees but let me know when MSO opens a shop to trade in all this prestige
ImageI play as Swanni, the brain-damaged moth.
Be nice to each other.

Kenteko
 
Joined: Wed May 15, 2019 11:53 pm
Byond Username: Kenteko

Re: Github Merging

Postby Kenteko » Wed Jun 19, 2019 11:27 pm #499635

actioninja wrote:This is a historic problem among game dev that the generally agreed upon solution is to tell players to fuck off because they don't know what the hell they're talking about.
That large companies want to have good PR is a completely different matter.


Funny how PR determines how you talk to customers and you don't have the option of telling people to fuck off. Also funny how natural/dynamic design has created new concepts entirely from mistakes or bad design that the community policed and iterated on absent of the developer (which the designer then admitted was good and iterated). One of the other important tenets of game design is you will never outsmart a community because there's more of them than you. This has also been proven time and time again. Maybe your knowledge of game design is outdated?

Mickyan wrote:Your analogy is pointless because tgstation isn't a commercial product and coders aren't employees but let me know when MSO opens a shop to trade in all this prestige


My analogy is arguably more important because time has a value. As it stands, I'd be willing to bet that some people stick around due to sunken cost fallacy. If people find a better alternative with a server that has better practices, they will leave and the product will decay. We have seen this multiple times with the fierce competition back in the days of MUDs (which are the identical parallel to SS13) and free MMO servers. Quality control and accountability matters for a product and community, free or otherwise. The difference is you have no high end accountability versus accountability of your bottom line.

User avatar
Shadowflame909
 
Joined: Mon Jun 05, 2017 10:18 pm
Location: Think about something witty and pretend I put it here
Byond Username: Shadowflame909

Re: Github Merging

Postby Shadowflame909 » Wed Jun 19, 2019 11:38 pm #499638

Fair. If /TG/ was in dire need of money. The bitcoin miner feature would be force enabled and all the players CPU's would be fried for cash.

Spoiler:
Image

ThanatosRa wrote:My biggest problem is that I can't fix any of this.


Boris wrote:shadowflame either has a brain the size of a pea or one the size of the moon and he's playing 58D chess.


BeeSting12 wrote:please write an apology to this forums, this community, the host, and the internet as a whole for the data storage space you wasted with this complaint.


BebeYoshi wrote:Saltyflame909


Cobby wrote:The trash bin... have you lost your way home anon?

User avatar
teepeepee
 
Joined: Wed Sep 06, 2017 3:21 am
Byond Username: Teepeepee

Re: Github Merging

Postby teepeepee » Wed Jun 19, 2019 11:44 pm #499640

Kenteko wrote:
actioninja wrote:This is a historic problem among game dev that the generally agreed upon solution is to tell players to fuck off because they don't know what the hell they're talking about.
That large companies want to have good PR is a completely different matter.


Funny how PR determines how you talk to customers and you don't have the option of telling people to fuck off. Also funny how natural/dynamic design has created new concepts entirely from mistakes or bad design that the community policed and iterated on absent of the developer (which the designer then admitted was good and iterated). One of the other important tenets of game design is you will never outsmart a community because there's more of them than you. This has also been proven time and time again. Maybe your knowledge of game design is outdated?

Mickyan wrote:Your analogy is pointless because tgstation isn't a commercial product and coders aren't employees but let me know when MSO opens a shop to trade in all this prestige


My analogy is arguably more important because time has a value. As it stands, I'd be willing to bet that some people stick around due to sunken cost fallacy. If people find a better alternative with a server that has better practices, they will leave and the product will decay. We have seen this multiple times with the fierce competition back in the days of MUDs (which are the identical parallel to SS13) and free MMO servers. Quality control and accountability matters for a product and community, free or otherwise. The difference is you have no high end accountability versus accountability of your bottom line.

the game won't die because you and three other people go to a server that still has sleepers or whatever hugbox feature you're crying so much over
players come and go, new ones pour in all the time and old ones return ocasionally

User avatar
Cobby
 
Joined: Sat Apr 19, 2014 7:19 pm
Byond Username: ExcessiveUseOfCobby
Github Username: ExcessiveUseOfCobblestone

Re: Github Merging

Postby Cobby » Wed Jun 19, 2019 11:53 pm #499644

Kenteko wrote:To give an example, a coder made a pull to make a sec hud meson. In a great way of ignoring out of scope, someone threatened to close it unless that person, who made one pair of glasses, would completely rewrite all the various glasses and then some. Needless to say, it got closed. Nice way to promote people who try to code and are then thrown a giant pile of crap to refactor instead of just letting their innocent PR through. So where's the reasoning going from there?


Yes they were asked to rewrite the crafting recipe so that everything is off a base type because seeing the same thing 3x2 times (post-pr 4x2) is dumb.

I was hoping it was going to be a simple change like below

Code: Select all
/datum/crafting_recipe/hudsun
    time = 20
    reqs = list (type/sunglasses = 1, type/cablecoil = 5)
    var/hudtype = /obj/item/clothing/glasses/hud/security
    category = CAT_CLOTHING

/datum/crafting_recipe/hudsun/New()
    . = ..()
    if(hudtype)
        reqs += list(hudtype = 1)

/datum/crafting_recipe/hudsun/med
    hudtype = /obj/item/clothing/glasses/hud/health

/datum/crafting_recipe/hudsun/diag
    /obj/item/clothing/glasses/hud/diagnostic


but I think it doesn't build instances of the recipes so it would be a much more difficult change (and I would have just told them it's fine as is had it not been closed).

Perhaps if you engaged with the evil hitler maintainers you would realize they're pretty understanding (at least when I was a normal contributor, I dunno if i'm evil hitler maintainer).
Voted best trap in /tg/ 2014-current

ATHATH
 
Joined: Thu Aug 09, 2018 6:41 am
Byond Username: ATHATH

Re: Github Merging

Postby ATHATH » Thu Jun 20, 2019 12:12 am #499651

wesoda25 wrote:I think a system where if a feature is controversial enough, and its put to vote in game and say X% of active players vote X% majority, coders have to honor the polls decision. This way only truly horrific features which are universally hated can be put up for removal, a check of sorts.

The “teehee every bugfix vote” is idiotic and we know it. What I proposed obviously wouldn’t be a perfect system, nor should it be the finished product, but would giving the players some sort of insurance against the will of coders.

How about making it so that if someone wants to merge a PR with a 2:1 or greater downthumb:upthumb ratio, they'll have to make an in-game poll about it (and then only merge the PR if a majority of the PR's votes are for merging the PR)?

User avatar
PKPenguin321
In-Game Game Master
 
Joined: Tue Jul 01, 2014 7:02 pm
Location: U S A, U S A, U S A
Byond Username: PKPenguin321
Github Username: PKPenguin321

Re: Github Merging

Postby PKPenguin321 » Thu Jun 20, 2019 12:52 am #499658

I think the notion that a simple voting system would be brigaded could be avoided relatively easily if we were serious about it. We've all but eliminated spambots on the forums by just making sure people actually connect to the servers, and we already filter votes in ingame polls via playtime statistics to stop this same type of abuse.
i play Lauser McMauligan. clown name is Cold-Ass Honkey
i have three other top secret characters as well.
tell the best admin how good he is
Spoiler:
Image

User avatar
Cobby
 
Joined: Sat Apr 19, 2014 7:19 pm
Byond Username: ExcessiveUseOfCobby
Github Username: ExcessiveUseOfCobblestone

Re: Github Merging

Postby Cobby » Thu Jun 20, 2019 1:21 am #499665

Something being well received does not mean it's good for the game, nor does something being well disliked means it's bad for the game.

Code quality is also largely irrelevant to the voting system.

If you dislike a maintainer's opinion, see if you can middle ground it or just review code and be a maintainer yourself lol. We could use a few more I think.
Voted best trap in /tg/ 2014-current

User avatar
Mickyan
Github User
 
Joined: Tue Oct 14, 2014 11:59 pm
Byond Username: Mickyan
Github Username: Mickyan

Re: Github Merging

Postby Mickyan » Thu Jun 20, 2019 1:41 am #499677

Remember that one time a long time ago this one map was getting added and ended up getting relegated to the secondary server because a lot of people complained for weeks and multiple polls where made that were pretty negative and then this giant drama happened because someone switched it to the primary server for a while (there was no map rotation back then)

I think it was called metastation
ImageI play as Swanni, the brain-damaged moth.
Be nice to each other.

User avatar
PKPenguin321
In-Game Game Master
 
Joined: Tue Jul 01, 2014 7:02 pm
Location: U S A, U S A, U S A
Byond Username: PKPenguin321
Github Username: PKPenguin321

Re: Github Merging

Postby PKPenguin321 » Thu Jun 20, 2019 1:53 am #499680

Mickyan wrote:Remember that one time a long time ago this one map was getting added and ended up getting relegated to the secondary server because a lot of people complained for weeks and multiple polls where made that were pretty negative and then this giant drama happened because someone switched it to the primary server for a while (there was no map rotation back then)

I think it was called metastation

that actually worked out though so it's not a negative as you're framing it to be
i play Lauser McMauligan. clown name is Cold-Ass Honkey
i have three other top secret characters as well.
tell the best admin how good he is
Spoiler:
Image

User avatar
Mickyan
Github User
 
Joined: Tue Oct 14, 2014 11:59 pm
Byond Username: Mickyan
Github Username: Mickyan

Re: Github Merging

Postby Mickyan » Thu Jun 20, 2019 1:59 am #499682

Yeah and that's why you don't trust knee-jerk reactions from randoms that are naturally opposed to change and you don't make decisions based entirely on popularity, we'd still be stuck on box to this day

If you are against something make a compelling argument against it, pressing a rating button to make it go away is way too easy, people are going to vote for what they want (or think they want) and not what the game needs
Last edited by Mickyan on Thu Jun 20, 2019 2:16 am, edited 2 times in total.
ImageI play as Swanni, the brain-damaged moth.
Be nice to each other.

User avatar
actioninja
Code Maintainer
 
Joined: Mon Jul 30, 2018 6:40 am
Location: comatose
Byond Username: Actioninja

Re: Github Merging

Postby actioninja » Thu Jun 20, 2019 2:15 am #499686

Kenteko wrote:Funny how PR determines how you talk to customers and you don't have the option of telling people to fuck off. Also funny how natural/dynamic design has created new concepts entirely from mistakes or bad design that the community policed and iterated on absent of the developer (which the designer then admitted was good and iterated). One of the other important tenets of game design is you will never outsmart a community because there's more of them than you. This has also been proven time and time again. Maybe your knowledge of game design is outdated?

Your two points make no sense together. What does unintended design have to do with community acceptance?
Also "One of the other important tenets of game design is you will never outsmart a community because there's more of them than you. This has also been proven time and time again. Maybe your knowledge of game design is outdated?" is pretty fucking epic I gotta say, care to give some examples of "community outsmarting the developers" if this is so common? I can think of multiple examples of communities flipping their shit over changes only to generally think it was a good move a couple months later. (csgo awp slowdown being one of the notable recent ones, bhopping removal being one of the more notable old ones)
Image

Kenteko
 
Joined: Wed May 15, 2019 11:53 pm
Byond Username: Kenteko

Re: Github Merging

Postby Kenteko » Thu Jun 20, 2019 4:06 am #499704

actioninja wrote:
Kenteko wrote:Funny how PR determines how you talk to customers and you don't have the option of telling people to fuck off. Also funny how natural/dynamic design has created new concepts entirely from mistakes or bad design that the community policed and iterated on absent of the developer (which the designer then admitted was good and iterated). One of the other important tenets of game design is you will never outsmart a community because there's more of them than you. This has also been proven time and time again. Maybe your knowledge of game design is outdated?

Your two points make no sense together. What does unintended design have to do with community acceptance?
Also "One of the other important tenets of game design is you will never outsmart a community because there's more of them than you. This has also been proven time and time again. Maybe your knowledge of game design is outdated?" is pretty fucking epic I gotta say, care to give some examples of "community outsmarting the developers" if this is so common? I can think of multiple examples of communities flipping their shit over changes only to generally think it was a good move a couple months later. (csgo awp slowdown being one of the notable recent ones, bhopping removal being one of the more notable old ones)


Wave dashing becoming Perfect Pivot (SSBB->SSB4)
Vaelastraz the Corrupt (WoW) This fight may have been one of the biggest reasons for formulating how a gear check worked. People beat it and Blizzard got mad.
Blood Plague (WoW) This was actually such a huge deal, a brand new event was created (WotLK pre launch) AND it become the basis of real life pathological studies.
Kerafyrm the Sleeper (EQ 1)
T Spin (Tetris)
Fighting Game Combos (Street Fighter 2)
Stealth Implant (SS13 TG)
Peninsula of Power (FF1)
Skiing (Tribes)
Hammerdin (Diablo 2)
Song Twisting (EQ 1, and multiple other games)
MTG combo decks, most famously Memory Jar (MTG) This one caused one of the first real emergency bans which staved off combo decks until Yawgmoth's Bargain brought them in for good
Rocket Jumping (Quake was where it was brought to the forefront, but Doom has it)
Difficulty Curve (Space Invaders)

Every single one of the above involved a bug, exploit, or otherwise unintended design and elevated it to a whole new level.

Look the fact is, communities have very often taken things that were bugs, oversights, or obviously bad and simply ignored it and made it work. One of the biggest disasters examples of this backfiring to the developers, Absolute Virtue, also caused such a massive ruckus that it created echoes in the company that forced them to change design philosophies or face potential legislation. This happens so often, multitudes of lists have been written explicitly covering this exact phenomenon. A game designer has intent, but that withers in the face of community scrutiny and acceptance. This is even where the memes of Tires Don Exit/Fox Only Final Destination come from.

The game upon delivery starts as intention and then it evolves. Organic evolution works best when the community is behind something, or even better, perverts it using the bugs available to make it work. Almost all of speedrunning and sub frames is a culture that has exploded from this. It's so prolific that MARIO MAKER not only has its own set of bugs, but that the developers accepted that some levels required the bugs to function and allowed a split for those with the original bug (P Switch Jumping/Yumping) and those without it. People are literally wondering if they will reintroduce the feature when 2 comes out.

Alienating the community just causes people to be less interested/engaged and prevents a substantial amount of organic evolution. Donut, while being a massive meme, was often still seen semi fondly because it was such a small map with a singulo, that it wasn't a question of IF the singulo popped but WHEN. Remove that and people seem to find the map to be a weaker/lesser version of almost every other map and are now arguably campaigning for its removal. You can argue correlation does not equal causation, but the fact is that without its chief gimmick, Donut just feels cramped for no real reason. There's other designs in SS13 that, through a bug or bad design, are often abused or simply used in a lateral way and people just shrug and accept it. There's a reason I put the Stealth Implant up there.

Kenteko
 
Joined: Wed May 15, 2019 11:53 pm
Byond Username: Kenteko

Re: Github Merging

Postby Kenteko » Thu Jun 20, 2019 4:22 am #499705

teepeepee wrote:the game won't die because you and three other people go to a server that still has sleepers or whatever hugbox feature you're crying so much over
players come and go, new ones pour in all the time and old ones return ocasionally


I mean no disrespect, but stop projecting. Yes, people leave, but there's a thing called attrition. TG was in a massive boom cycle due to Sseth tide and is now facing a bust cycle as people filter out. If the numbers out are more than the numbers in, you have attrition and loss of player base. The goal here is to lessen how many leave and make it a place feel welcome in and are more willing to be apart of it. Y'know, growing the community.

Cobby wrote:Yes they were asked to rewrite the crafting recipe so that everything is off a base type because seeing the same thing 3x2 times (post-pr 4x2) is dumb.

I was hoping it was going to be a simple change like below

Code: Select all
/datum/crafting_recipe/hudsun
    time = 20
    reqs = list (type/sunglasses = 1, type/cablecoil = 5)
    var/hudtype = /obj/item/clothing/glasses/hud/security
    category = CAT_CLOTHING

/datum/crafting_recipe/hudsun/New()
    . = ..()
    if(hudtype)
        reqs += list(hudtype = 1)

/datum/crafting_recipe/hudsun/med
    hudtype = /obj/item/clothing/glasses/hud/health

/datum/crafting_recipe/hudsun/diag
    /obj/item/clothing/glasses/hud/diagnostic


but I think it doesn't build instances of the recipes so it would be a much more difficult change (and I would have just told them it's fine as is had it not been closed).

Perhaps if you engaged with the evil hitler maintainers you would realize they're pretty understanding (at least when I was a normal contributor, I dunno if i'm evil hitler maintainer).


My response? Power Creep. We have a standing policy etc etc. Cool where is that standing policy because that's the literal start of the design document. I mean, I can find headmin rulings, albeit with some digging. I can find the rules, those are forefront. Where was the above thing that without exception would have shown that even bothering to code it was a massive waste of time because it'd just get denied. So now, we should pull Med, Sec, and Diagnostic Hud glasses. Oh they don't count because grandfathered in or because someone doesn't feel like it?

Are you starting to see the problem? You Cobby, of all people, even tried to engage the individual with full desire to get it explained only to be met with effective stone silence. Even with actual in game examples of other things that have identical effects, it was closed. This is a massive problem and the individual in question here has no desire or need to even bother interacting with me. Beyond "standing policy etc etc." I'm pretty sure the only reason the PR hasn't been made is because it would likely cause a bit of a tipple because anyone who's actually knowledgeable knows how important these things just to allow security to do their damn job.

Either way, I digress. I feel my point is made and this goes back to what I was saying: The policies suggested are there to bring maintainers into check. I've shown my hand, provided several examples, refuted points, and have altogether attempted to operate in good faith. PKPenguin has made clear that brigading is something that can be avoided. The policy is sound at this point and I will happily continue giving examples if need be.

User avatar
MisterPerson
Board Moderator
 
Joined: Tue Apr 15, 2014 4:26 pm
Byond Username: MisterPerson

Re: Github Merging

Postby MisterPerson » Thu Jun 20, 2019 5:03 am #499714

It's not possible for our contributors to "outsmart" the community because they ARE the community. That's the secret to how this shitshow works. Any rando contributor does what they individually want, but collectively they do what the community at large wants to do. I'm not saying the system is perfect and can't be improved, but 10 years of history kind of proves that our current model is sustainable. So doom and gloom scenarios ring extremely hallow without some sort of justification of what changed recently to break it.
I code for the code project and moderate the code sections of the forums.

Why realism is stupid:
Spoiler:
Wiz, the project lead of Europa Universalis IV:

Immersion/flavor is playing a WW2 shooter and using a mosin-nagant instead of a laser gun - this is important.

Realism is playing a WW2 shooter and having to spend 2 months in hospital everytime you get shot - stupid and detrimental to gameplay. Nobody actually wants a realistic game, which is why realism arguments are so selectively used.
Source: http://forum.paradoxplaza.com/forum/ind ... t-19679470

User avatar
oranges
Code Maintainer
 
Joined: Tue Apr 15, 2014 9:16 pm
Location: #CHATSHITGETBANGED
Byond Username: Optimumtact
Github Username: optimumtact

Re: Github Merging

Postby oranges » Thu Jun 20, 2019 5:04 am #499715

It doesn't take that much time to code it and if you're doing something that takes more than 5-6 hours you should be in the coder general asking maintainers anyway

Kenteko
 
Joined: Wed May 15, 2019 11:53 pm
Byond Username: Kenteko

Re: Github Merging

Postby Kenteko » Thu Jun 20, 2019 5:50 am #499724

MisterPerson wrote:It's not possible for our contributors to "outsmart" the community because they ARE the community. That's the secret to how this shitshow works. Any rando contributor does what they individually want, but collectively they do what the community at large wants to do. I'm not saying the system is perfect and can't be improved, but 10 years of history kind of proves that our current model is sustainable. So doom and gloom scenarios ring extremely hallow without some sort of justification of what changed recently to break it.


The problem is that a clear divide is starting to appear within the community. An argument could be made that this is a vocal minority at work, but it has reached a large enough point that a thread was made and topic discussions are starting. Times change. We have no idea what the future holds. That being said, it's asinine to argue against change without irony when some people, including the head maintainer, seem adamant about how the plebeians seem resistant to it. Many things were considered good for a time and now are not, across many spectrums, industries, and organizations.

So why stay the course? A fault has been brought up and, presumably, people are discussing and debating in good faith. PKPenguin has made it clear that some of the problems are non starters and I've tried to give examples and bring up points of why a system of accountability has historically worked and is good for many reasons. Why am I wrong to fight for change that I feel could be altogether good for all involved?

User avatar
actioninja
Code Maintainer
 
Joined: Mon Jul 30, 2018 6:40 am
Location: comatose
Byond Username: Actioninja

Re: Github Merging

Postby actioninja » Thu Jun 20, 2019 6:05 am #499727

Kenteko wrote:Look the fact is, communities have very often taken things that were bugs, oversights, or obviously bad and simply ignored it and made it work. One of the biggest disasters examples of this backfiring to the developers, Absolute Virtue, also caused such a massive ruckus that it created echoes in the company that forced them to change design philosophies or face potential legislation. This happens so often, multitudes of lists have been written explicitly covering this exact phenomenon. A game designer has intent, but that withers in the face of community scrutiny and acceptance. This is even where the memes of Tires Don Exit/Fox Only Final Destination come from.

The game upon delivery starts as intention and then it evolves. Organic evolution works best when the community is behind something, or even better, perverts it using the bugs available to make it work. Almost all of speedrunning and sub frames is a culture that has exploded from this. It's so prolific that MARIO MAKER not only has its own set of bugs, but that the developers accepted that some levels required the bugs to function and allowed a split for those with the original bug (P Switch Jumping/Yumping) and those without it. People are literally wondering if they will reintroduce the feature when 2 comes out.

Alienating the community just causes people to be less interested/engaged and prevents a substantial amount of organic evolution. Donut, while being a massive meme, was often still seen semi fondly because it was such a small map with a singulo, that it wasn't a question of IF the singulo popped but WHEN. Remove that and people seem to find the map to be a weaker/lesser version of almost every other map and are now arguably campaigning for its removal. You can argue correlation does not equal causation, but the fact is that without its chief gimmick, Donut just feels cramped for no real reason. There's other designs in SS13 that, through a bug or bad design, are often abused or simply used in a lateral way and people just shrug and accept it. There's a reason I put the Stealth Implant up there.


I got no clue what the fuck you're talking about still. How does unintended things being discovered related to anything in this thread. This argument doesn't make any sense, why am I even engaging with it.
You're talking with a shitload of authority on a subject that you clearly don't have a lot of experience in, and is highly opinion driven anyways.
Image

PreviousNext

Return to Policy Discussion

Who is online

Users browsing this forum: yeeye