/tg/Station 13

so, basically, why does oranges keep merging heavily disliked stuff? shouldnt there be something that prevents him from merging (policy wise) without considering what the community wants?
Examples:
https://github.com/tgstation/tgstation/pull/44324
https://github.com/tgstation/tgstation/pull/44530
https://github.com/tgstation/tgstation/pull/42386
all of these were heavily disliked, yet oranges still merged them.

dont get me wrong here, this isnt just oranges, but hes doing most of it.


also a gem i found in my pics, god bless his soul

DIVISION BETWEEN THE SERVER AND THE CODEBASE IS-

you answered your own post with a post inside your post.

Probably the most intelligent deitus post I’ve ever seen. But to a degree I feel a “dictator” like codebase is necessary, because the masses really never do seem to know what they actually want. In some select cases its seemed almost antagonistic of the coders to keep certain features, especially when votes have proven they are in the minority. But I suppose thats the price we have to pay for the stability that figures such as oranges bring to SS13.

bobbahbrown wrote:you answered your own post with a post inside your post.

my point is it shouldn't be like that

just because a majority vote agrees on something doesn't make it a good idea

wesoda25 wrote:because the masses really never do seem to know what they actually want

i mean, there is a player poll feature and when was the last time a testmerge got unmerged?

Screemonster wrote:just because a majority vote agrees on something doesn't make it a good idea

yea, some of this may not seem like a good idea, but that's what the players want, and not for it to be removed.

Timonk wrote:

wesoda25 wrote:because the masses really never do seem to know what they actually want

i mean, there is a player poll feature and when was the last time a testmerge got unmerged?

It’s usually rare for a feature removal of testmerge stuff bc for it to be testmerged in the first place, coders are usually on board. By the test merge, any flaws coders see are ironed out and its deemed ready for the game. Theres been lots tho im sure, none I could list off the top of my head tho.

This isn't for Policy Discussions - the administration (including the headmins) have no greater say in what gets merged then the average player does.

If you're interested in asking oranges about his rationale I suggest posting in the coding subforum - Coding or Feedback, probably.

Arianya wrote:This isn't for Policy Discussions - the administration (including the headmins) have no greater say in what gets merged then the average player does.

If you're interested in asking oranges about his rationale I suggest posting in the coding subforum - Coding or Feedback, probably.

Not sure why you locked this thread after this post. I believe the suggestion is to reform the current system into a policy that the server has some say over, which is a valid point of discussion in here, like it or not.

A "democratic" pull request process is absolutely something that could hypothetically be put in place as a policy.

Game design is not and should not be a popularity contest

PKPenguin321 wrote:

Arianya wrote:This isn't for Policy Discussions - the administration (including the headmins) have no greater say in what gets merged then the average player does.

If you're interested in asking oranges about his rationale I suggest posting in the coding subforum - Coding or Feedback, probably.

Not sure why you locked this thread after this post. I believe the suggestion is to reform the current system into a policy that the server has some say over, which is a valid point of discussion in here, like it or not.

A "democratic" pull request process is absolutely something that could hypothetically be put in place as a policy.

That's incredibly wild hypothetical on your part - realistically one that could only be implemented by fork of the codebase or the codebase ceding to it. Regardless, this thread is in violation of the Policy Discussion rules:

4.) This board is for discussing in-game administrative policy and rules, including in-game server configuration; coding policies and rules is discussed in #coderbus viewtopic.php?f=2&t=150

SpaceManiac wrote:Game design is not and should not be a popularity contest

Strong agree. Its good that players are interested in the state of the game and its development direction. They should actively share how they feel about changes and make/suggest some. But many necessary changes would not currently exist if every change were subject to even more political games and hand wringing. Getting to vote about changes feels good for the randoms that cast votes, but merely playing the game does not grant special insight into how the game functions nor does it provide a stable field on which the game can be developed.

This also opens the door to code changes by coders people like for reasons other than their code gaining more support for their changes not because they are good changes, but because the coder is popular or charismatic and pulls more people to upvote their code.

Keep democratic memes out of the codebase

yeah let's do a global player poll on every server for every PR before it gets merged, even minor bugfixes, there are no downsides to this at all
unless you're saying a pr being merged or not should be decided by the upvotes and downvotes it gets on github, which is even funnier honestly

Arianya wrote:

4.) This board is for discussing in-game administrative policy and rules, including in-game server configuration; coding policies and rules is discussed in #coderbus viewtopic.php?f=2&t=150

Going to say that this is superseded by the act of proposing new policy, which I explicitly allowed in the board guidlines (see https://tgstation13.org/phpBB/viewtopic ... 33&t=11057)
Normally coding changes would be moved out, yes, but this thread is specifically about proposing a new server policy that handles how we interact with code.
Whether what's proposed in this thread is a good idea or not should be discussed, and whether it should be locked and resolved is up to headmins (or on rare occasion a moderator if the thread goes wildly out of hand), not you.

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.

cedarbridge wrote:

SpaceManiac wrote:Game design is not and should not be a popularity contest

Strong agree. Its good that players are interested in the state of the game and its development direction. They should actively share how they feel about changes and make/suggest some. But many necessary changes would not currently exist if every change were subject to even more political games and hand wringing. Getting to vote about changes feels good for the randoms that cast votes, but merely playing the game does not grant special insight into how the game functions nor does it provide a stable field on which the game can be developed.

This also opens the door to code changes by coders people like for reasons other than their code gaining more support for their changes not because they are good changes, but because the coder is popular or charismatic and pulls more people to upvote their code.

Keep democratic memes out of the codebase

I would agree if maintainers actually gave a damn about quality control.

So many controversial obviously bug filled Prs getting merged.

We need a little bit more than just the bare minimum that is instantly closing the obvious meme PRs.

Coders should be forced to fix the issues in their ideas if they want it merged. A half-baked idea only harms the people that actually play the game.

Tsk tsk tsk.

Exactly which part of "give a bunch of non-coders a vote on what counts for good code" suddenly makes the code better? You don't make the NBA better by having the fans in the bleachers write the rules.

cedarbridge wrote:Exactly which part of "give a bunch of non-coders a vote on what counts for good code" suddenly makes the code better? You don't make the NBA better by having the fans in the bleachers write the rules.

Fans of the NBA don’t play the game.

wesoda25 wrote:

cedarbridge wrote:Exactly which part of "give a bunch of non-coders a vote on what counts for good code" suddenly makes the code better? You don't make the NBA better by having the fans in the bleachers write the rules.

Fans of the NBA don’t play the game.

You're right. They pay for the tickets and attend the game. You log onto a server running the codebase's code. They play the game you want a hand in: the code.

Jimmius wrote:yeah let's do a global player poll on every server for every PR before it gets merged, even minor bugfixes, there are no downsides to this at all
unless you're saying a pr being merged or not should be decided by the upvotes and downvotes it gets on github, which is even funnier honestly

Maybe a mix of that? Make a player poll for controversial PRs?

cedarbridge wrote:

wesoda25 wrote:

cedarbridge wrote:Exactly which part of "give a bunch of non-coders a vote on what counts for good code" suddenly makes the code better? You don't make the NBA better by having the fans in the bleachers write the rules.

Fans of the NBA don’t play the game.

You're right. They pay for the tickets and attend the game. You log onto a server running the codebase's code. They play the game you want a hand in: the code.

I mean the NBA viewers are basically the audience on YouTube, etc. and we are the basketball players?

Timonk wrote:

cedarbridge wrote:

wesoda25 wrote:

cedarbridge wrote:Exactly which part of "give a bunch of non-coders a vote on what counts for good code" suddenly makes the code better? You don't make the NBA better by having the fans in the bleachers write the rules.

Fans of the NBA don’t play the game.

You're right. They pay for the tickets and attend the game. You log onto a server running the codebase's code. They play the game you want a hand in: the code.

I mean the NBA viewers are basically the audience on YouTube, etc. and we are the basketball players?

How on Earth did you come to such a terrible conclusion?

Because we play the game while the greedy team owners make terrible business decisions

This basketball analogy is clearly too confusing, if it's so easy to equate "playing spacemans" with "playing pro basketball" just because they're both called "playing".

Coding involves work. The best way to influence the direction of the codebase is to put in that work.

I'm sick of all the work being half-assed and being accepted.

Because ultimately it harms the player.

The player is sick of being abused! aaaaa

I can’t really think of a better system than what we have here. While there are some moments that I think democracy would be better, there are also moments where something is changed for the better despite all people wanting otherwise separated chemicals

Outside the scope of this, but I always thought there was a 24 hour rule to merging new pull requests?

Realistically, and on topic, nothing will change.

SpaceManiac wrote:This basketball analogy is clearly too confusing, if it's so easy to equate "playing spacemans" with "playing pro basketball" just because they're both called "playing".

Coding involves work. The best way to influence the direction of the codebase is to put in that work.

I'm guessing that's the only way that metaphor got confused. "I consume the thing so I'm best suited to dictate how the thing is made" makes no sense in either of those cases.

Shadowflame909 wrote:Because we play the game while the greedy team owners make terrible business decisions

Entitlement without actual entitlement.

bring back kor

return the slime to us

I actually agreed with pretty much of all of Kors design decisions but I'm still unsure if there was actually a point of time, even in Kor's time. That people actually had any convincing power over the maintainers.

Basically oligarchs now.

Which makes me quite the aggro'd gamer when broken half-baked PRs get merged instead of maintainers forcing lame shitters to fix their own PRs.

I know that even the current maintainers don't give a fuck about the current issue tracker (Some of them do. I guess, otherwise that whole code lock-down thing would have never happened.) But I don't think we should just allow code to break mechanics and gimmicks very noticeably and just wait for someone else to code a fix for it because you like the PR.

That's so lazy and WYCI is going to crash and burn /tg/station with no survivors because with minimal design direction other then "shake up the meta to keep power-gamers on their toes" and "nerf this old feature because players have gotten too reliant on it" you're going to end up in a state of entropy where the game literally is too convoluted to do anything enjoyable anymore.

So yeah, you're going to turn us into paradise maintainers!

SpaceManiac wrote:Game design is not and should not be a popularity contest

are you telling me you would merge something that literally nobody wants?

Timonk wrote:

SpaceManiac wrote:Game design is not and should not be a popularity contest

are you telling me you would merge something that literally nobody wants?

hello i wanted all three of the prs in the OP merged

Timonk wrote:yea, some of this may not seem like a good idea, but that's what the players want, and not for it to be removed.

So say this topic inspires new policy and the community gets a greater say in merges. Hypothetically, let's say something unpopular needs to get merged and, in hindsight, that thing will be good for the server. Do you think the community would be able to make the right choice and allow it to be merged?

If it needed to be merged then it wouldn't be unpopular.

Sorry gamer, but the maintaners and the players want a whole different game.

Shadowflame909 wrote:If it needed to be merged then it wouldn't be unpopular.

Do you believe this will be the case every single time there's an unpopular PR? Why should we trust the community's foresight?

IkeTG wrote:

Shadowflame909 wrote:If it needed to be merged then it wouldn't be unpopular.

Do you believe this will be the case every single time there's an unpopular PR? Why should we trust the community's foresight?

Do you really think the majority of players wanted seperated chems and null crates removed? Emagging the cargo console is basically useless now unless you want that static weak gamer gear for 5k or so

Timonk wrote:Do you really think the majority of players wanted seperated chems and null crates removed?

That wasn't my question.

Kinda answered that first part though

IkeTG wrote:

Shadowflame909 wrote:If it needed to be merged then it wouldn't be unpopular.

Do you believe this will be the case every single time there's an unpopular PR? Why should we trust the community's foresight?

Because I have no reason not to.

You're arguing that oranges doesn't give a good enough reason why something was merged, but here you are not giving a good enough reason why something shouldn't be merged. How would applying this topic's policy change anything except making a force in the codebase that's way harder to hold accountable?

No, I'm upset that so much broken code gets merged and the maintainers shove it onto other people to fix it. "eventually"

If the bug is obvious, then the coder should fix their own shit before it gets merged. We shouldn't accept the half-baked code.

That's all I'm saying. If the maintainers aren't willing to do so. Then maybe the players would have more interest in the quality of life of /tg/station. Since they're the ones actually dealing with it.

You're trying to frame the issue of bugs as a matter of laziness or irresponsibility because it's easier to attack those two points. "If the bug is obvious..." If all the bugs are so obvious, why are all the players, who in your eyes are perfectly capable of vetting merges, not fixing them right now?
If you want meaningful change you need to make a good, solid case for the change. Otherwise, you're just beating around the bush and squabbling over what if's.

That's the problem. We have over 1000 bugs that the maintainers seemingly don't care about because of how "wonky" the issue tracker is.

We don't need any PRs adding more of them.

It's a quality of life thing. And maintainers aren't living up to quality control.

The only real aspect of that I've seen is just instantly closing meme PRs as PK Penguin adds in a dildo PR. Or another counter-nerf PR's that happen out of outrage.

I just want more quality control.

Because of the current standard of accepting quirks and issues within a PR only makes the game worse.

Also Hint, if the ever-growing issue logger isn't a sign. Those issues don't get fixed.

You're saying quality control but you aren't making a visible case as to what you mean by quality control or how you think one could work towards achieving this quality control. This is a good example of why giving players a say in what gets merged would make things more confusing and less efficient, simply because a lot of players would say Thing Bad but couldn't feasibly elaborate on workable solutions or alternatives.

itt people with no understanding of how to run a codebase

Separated chems were cancer, good PR. Null crates were cancer, good PR. Autocloning was cancer, good PR.

If you’re gonna quote features for your argument at least address stuff like hygiene.

If you want some examples. When I look at the recent PRs. I get really annoyed at the disregard of simple mob functions and their antagonists. You nerfed dragging but gave people a feasible alternative. (Almost didn't exist until PKpenguin came up with the idea. But the execution ended up just being another roundabout minor movement speed nerf.) The problem with this was, is that simple mobs were not addressed and ultimately ignored. Because "They're not important enough for me to care" as oranges put it so eloquently.

On another example, stasis. It left some gaps to fill in medbay as it made doctors even more useless and forced people to rely on an unreliable role. It wasn't a 1:1 replacement as the maintainer who merged it put it, and hoped that it would inspire people either out of anger or frustration to fix medbay themselves.

It didn't, and the maintainer themselves had to add in a bit more to keep medical doctors busy.

These issues would both be addressed by some quality control that I'm looking for. A simple, "Your PR has issues like ___ and until they get fixed. This is simply not compatible with our code-base."

You cannot rely on people to care about things that do not affect them. You have to give them a reason to care. Maybe a coder would fix the botched PRs after a month passes and they realize "Hey. Why does this role suck so much? How come no one fixed this?" But I feel like this could ultimately be more easily addressed by just having the original person. Either fix it or not merge their half-baked idea at all.

To simply put it. I want it to be the original coder's problem. They only care whether their nerf PR gets merged or not. Why shouldn't the maintainers make them care about the issues their nerf PR brings up?

This is what confuses me.