Leaderboard

I have noticed a massive decrease in communication and transparency on the github ever since PR voting has been split into different design teams. It's to a point where I myself no longer want to contribute to this server as it is a massive morale zap to see your PR closed with little to no communication from the different teams. I think it'd be productive to see exactly why and how the different teams are voting on PRs the way they are. There's no reason for our PR review process to be private, we are an open-source codebase. Do note the differences between visible and public. I am calling for all development channels to be made visible meaning that anyone can read them but not talk in them.

I am not sure if making the development channels would help that much. What i am sure of is that PRs being closed with no obvious reasoning (its different than lets say a PR with lots of comments and discussions where it would be clear why that one objection happened) DO inflict a massive morale zap on contributors. I would KILL for an reasoning about the banana cream pie (zero comments on the PR, zero discussion over discord by people in general), is it because we dont want effects that could be annoying? The sound chosen by the author was not good enough? Is it a worry that it could somehow be abused to annoyance because it would make cream pie launcher have an actual impact? Why should i add sounds to any items if i am not even sure why a similar PR got denied?! Our human resources are limited and will stay that way if we keep losing people because of avoidable frustrations.

I took 15 minutes to look at some data just to ensure we are not holding this discussion based on emotions and I-feel-likes, because this topic is leading to nowhere. Since 12 January, 300 PRs were handled of which 40 got closed. At maximum, 11 of those got rejected visibly on GitHub, of which 4 did not get a written reply as to why. This is a solid 100 PR / month with a little over 1 getting rejected without an explanation on GitHub (not counting the possible discussion between the PR opener and the maintainers on Discord). PR closed/abandoned by their author for personal/technical reasons or they made an alternative PR (28): https://github.com/ParadiseSS13/Paradise/pull/20417 https://github.com/ParadiseSS13/Paradise/pull/20400 https://github.com/ParadiseSS13/Paradise/pull/20378 https://github.com/ParadiseSS13/Paradise/pull/20377 https://github.com/ParadiseSS13/Paradise/pull/20374 https://github.com/ParadiseSS13/Paradise/pull/20373 https://github.com/ParadiseSS13/Paradise/pull/20365 https://github.com/ParadiseSS13/Paradise/pull/20364 https://github.com/ParadiseSS13/Paradise/pull/20358 https://github.com/ParadiseSS13/Paradise/pull/20355 https://github.com/ParadiseSS13/Paradise/pull/20338 https://github.com/ParadiseSS13/Paradise/pull/20318 https://github.com/ParadiseSS13/Paradise/pull/20317 https://github.com/ParadiseSS13/Paradise/pull/20316 https://github.com/ParadiseSS13/Paradise/pull/20296 https://github.com/ParadiseSS13/Paradise/pull/20292 https://github.com/ParadiseSS13/Paradise/pull/20647 https://github.com/ParadiseSS13/Paradise/pull/20633 https://github.com/ParadiseSS13/Paradise/pull/20624 https://github.com/ParadiseSS13/Paradise/pull/20557 https://github.com/ParadiseSS13/Paradise/pull/20555 https://github.com/ParadiseSS13/Paradise/pull/20510 https://github.com/ParadiseSS13/Paradise/pull/20475 https://github.com/ParadiseSS13/Paradise/pull/20446 https://github.com/ParadiseSS13/Paradise/pull/20269 https://github.com/ParadiseSS13/Paradise/pull/20212 https://github.com/ParadiseSS13/Paradise/pull/20210 https://github.com/ParadiseSS13/Paradise/pull/20186 PR closed by maintainers stating the reason on the PR (5): https://github.com/ParadiseSS13/Paradise/pull/20406 https://github.com/ParadiseSS13/Paradise/pull/20357 https://github.com/ParadiseSS13/Paradise/pull/20272 https://github.com/ParadiseSS13/Paradise/pull/20235 https://github.com/ParadiseSS13/Paradise/pull/20202 PR closed by maintainers without stating a reason on the PR (4): https://github.com/ParadiseSS13/Paradise/pull/20396 https://github.com/ParadiseSS13/Paradise/pull/20386 https://github.com/ParadiseSS13/Paradise/pull/20382 https://github.com/ParadiseSS13/Paradise/pull/20205 Either dev objection on Discord or personal, could not decide (1): https://github.com/ParadiseSS13/Paradise/pull/20370 Dev objection on Discord, not stated on the PR (2): https://github.com/ParadiseSS13/Paradise/pull/20509 https://github.com/ParadiseSS13/Paradise/pull/20178

Me and Marm relishing in our crate organization skills.

Jack Rheiner the seccie

It's a perspective thing. If you compared the development cycle from uhh idk around 2017 when I first started playing, of course, things are better now. I am just noticing things slipping back, it's hard to see that happen considering the strides in progress that have been made lately on the development side of things. I am always going to be a pro-transparency purest, that's just who I am and what I believe in. Some wise old man would probably tell you and me that the solution lies somewhere in the middle.

full disclosure, i am an (extraordinarily inconsequential) member of the dev team. despite this, and being in the private dev channel, i *also* don't see the vote tracker, so publicizing the private dev channel (specifically, distinct from the vote tracker) wouldn't change the result whatsoever, because not every decision is made in a town hall setting complete with peanut gallery, nor should they, nor can they. for my part--without retreading the existing (salient) dicussion points regarding admin energy/burnout/harassment; that not everyone *should* be a part of every conversation, even as an observer; and that 99.9% of the time the "problem" is just that maintainers have lives and are busy and things fall between the cracks, which won't change if decision-making is publicized--i think: to say "right now we get nothing but a yes or no", followed by affected and charlie posting PR comments that are *not* just a yes or no, followed by saying "i don't know why you're cherry picking examples", and then "sometimes we do get explanations but" is self-defeating. if your argument is "right now we get nothing but a yes or no", and the response is direct, objective, contradictory evidence, it's hard to take the assertion seriously. if the argument is that this is a slowly aggregating trend, then you need a trend *line*. in other words, specific, objective data showing the difference between how many PRs have been closed with no explanation between the previous dev policy and now. people's feelings and impressions about the situation aren't going to cut it (especially the kinds of comments that start with "it just seems that"), especially since contributors tend to place disproportionately high emotional value on their PRs, either because of the time spent, the emotional investment in the community, the perceived quality/value of the implementation, the hope for the desired outcome, or the jarring nature of normally having one's PRs accepted only to have one specific one denied. admins are not responsible for anticipating and shaping the emotional reaction of contributors. the dev team already walks on eggshells to try and work against this. the policy shouldn't be tailor-made to optimize against emotional blowback from contributors. i've lost track of the number of times i've heard that transparency in decisions like this is _ipso facto_ better than opacity but the impetus for this discussion seems to be that the lack of transparency discourages contributors. there are already plenty of venues and opportunities for contributors to get blessing to work on something: in a design doc, in a github discussion, in the discord. putting names to decisions only gives contributors ammunition against individuals, which is precisely why things are the way they are now. never explaining decisions discourages contributors. always publicizing decisions discourages the dev team. that's why we have two phases to the process, the public decision making venues, and the final say the dev team has. i think there's a belief that if this level of transparency is enacted people will suddenly discover their PRs are being denied for nefarious, petty reasons, and not just what it is now, which is things fall through the cracks, the dev team is busy, miscommunication happens. the vote against on the banana cream pie sound effect PR is an individual instance of a PR denial by a member of the admin team for no stated reason, which was allowed *before the new dev team structure and policies*. is not an indictment of the current dev policy writ large, or a microcosm of the behavior of all of the dev team. the failure to share an explanation here is a *mistake*, not an enforcement of the new policies, and considering we are all fallible humans adapting to a new organizational structure, things like this are bound to happen. in other words (or the same words as above, which apparently require incessant repetition): maintainers have lives, are busy, and things fall through the cracks. if this was allowed under the old dev team structure/policies, then asking for the old dev team structure/policies back will make this happen _more_. like, the thing you want back is the thing that caused the thing you don't want to occur. and if the PR author *is* discouraged, there are already venues for the PR author to request clarification in cases like this. they can ping the team in discord; they can DM the admin who closed the PR; they can post a thread; they can reply on the PR since closing a PR does not lock the comment thread, that's a separate action; they can even (but i'd save this for the most egregious cases) file an admin complaint on the forums, after all, voting against a PR is an admin action. ultimately, by being a contributor, you're placing trust in the admin team to maintain the trajectory of the game and community. the admin team already goes above and beyond in terms of organizational transparency: you know the name of every admin member, mentors and admins are selected on an evidentiary basis with an application process and standards team members are expected to uphold; every ban appeal is publicized, every admin complaint is publicized, affected not only provides public profiling and round stat APIs, they also bust their ass every year to put together a state of the server sharing all the salient highlights of codebase and production development; the entire development team policy is public, and i can guarantee that there are no dev team members who don't uphold themselves to those policies. the dev team channel isn't private because we have something to hide; it's because there needs to be a place where lightweight, informal conversation can occur without input from a peanut gallery or disproportionate hysteria in response to non-binding or casual discussions of the game without firm conclusions before official decisions are made and properly communicated to the community, and there needs to be a way for individual admins to perform their functions without worrying about emotionally overinvested gamers keeping excel spreadsheets of all the times they feel they've been wronged, personally and deeply, by Admin Alice or Headcoder Harry.

you may vibe with this then, made by octus https://github.com/ParadiseSS13/Paradise/pull/20402

I massively agree that votes should be public information. I've benefited from seeing who's voted and been able to approach them to see what they'd like changed for a PR to be merged. Rarely it's "no I dont see this working at all", often it leads to changes and a merged PR. If someone harasses a voter on a subject, it's easy for us to take action against them. We don't want genuine harrassment in our community. Sadly the word "harassed" has been used in the past as a catch-all for people disagreeing with others in DMs, this isn't really harassment it's just creative differences. But we can take action against genuine problem people. The private dev channel is not some secret cabal of balance discussion. It happens sometimes but most of the time it's people pinging others regarding reviews and neeing to vote, people discussing explots that have been reported (this is very common as we have a lot of currently reported exploits), and charlie shittalking about banning everyone who disagrees with him. I don't think that being open for viewing would achieve anything apart from hinder discussion on genuinely private topics.

Right before I even go into the actual meat of this post I want to explain how the voting system actually works just to clear up any confusionwith it. Internally, we have a tracking system for each PR which can have approvals or objections, under the category of design or balance. These objections can only be applied by the relevant teams (IE - Someone in balance team cant throw a design objection on a PR). The PR type depends on the votes needed (99% of them need the design team, Balance PRs need the balance team obviously). If you are a member of both teams and a PR needs both votes, you only get one. It is not compulsory for a PR to get everyone to vote on it, if that was the case we would be here forever, hence why its on a majority system. However, if a PR has no approvals and only a singular objection, we tend to leave it open until expiration date (30 days) and nag people internally for votes just to make sure they havnt missed it. It is a common occurance for someone's thoughts on a PR to be indifferent, as in they dont have it enough to object, but dont really approve of it, its just "meh" to them, hence no vote. A PR can go without approval but not have objections either. I should point out all of this is outlined on https://paradisestation.org/dev/policy/ Now for the post itself. This is absolutely incorrect. The split into teams has bought on more people who are actually willing to write objections out onto PRs instead of hitting a button behind the scenes and not caring. If you take a before And an after I really dont see the argument here When you wake up to 3 death threats (no this is not hyperbole) and nagging over the most minute of objections, you will see why sometimes we keep quiet about objections, especially if the PR is likely to get you absolutely slated for it. I also want to cite this from the GitHub code of conduct, specifically the first sentence. It is also worth nothing we do ask people from the teams to try state their issues more The PR tracker could potentially be opened up, but that will be a lot of tape crossing and policy changes. However, the internal development chat will never be opened up, purely because: Exploit discussion Discussion on disciplinary action on other GitHub contributors We really dont need the frothing masses berating us when we even think slightly about a possible rework TLDR - The system itself isn't flawed and people did use to state objections, theres just been a dropoff of it with burnout among other things, and we are working on it.

If someone is going out of their way to harass a maintainer for voting a certain way then they should be banned, simple as that. Being able to see why the X design team voted the way they did and their thought process behind that would lead to a greater understanding of what went wrong. Right now we get nothing but a blank yes or no which in the case of the latter is nothing more than an absolute insult to said contributor as you are talking about potentially hours of someone's free time being flushed down the drain with no explanation. I don't see any downsides to making the channels visible, most counterarguments honestly feel like a strawman of 'somebody' 'potentially' harassing the maintainers when the obvious answer to that is to just ban people who do that. Also, this adds zero extra strain on the development team, they don't need to come out with a statement every time a PR is closed or merged, you could just look at the respective design channel and figure it out yourself. Many other servers already have their development channels visible and I think we would clear up a lot of frustrations by following in their footsteps.

Making the channels visible sounds like a poor idea. While I do believe our contributors are mature enough to simply accept decisions of the respective teams, I am less confident in non-contributors. I can very easily see random people championing PRs they like in DMs of relevant team members instead of on GitHub. I'd rather avoid sending overly upset people at anyone. Henri's idea would increase the workload of the teams, but probably not by a whole lot. We all know and love the anecdote of "yeah, no" being the whole input from maintainers before a PR was veto'd. While the teams alleviated many issues, this kind of pops up as one from time to time. Ideally, I think, the team that ended up objecting to a PR should leave a brief comment on the PR. Nothing exhaustive, but just enough to not leave people confused. Maybe I'm just stupid and it's somehow obvious, but admittedly sometimes I don't even know which team objected to a specific PR.

These are some rather complex new solutions when we already have a working solution in-game, but for crew-based objectives: When your assassinate target - for example - moves into cryo storage, you automatically get a new target. If object-based objectives worked the same way if/when they were destroyed that would solve this issue (only no-longer working when all steal-able items were destroyed - at which point you probably have bigger issues). This avoids having objective items order-able (in which case every object objective becomes - emagg the cargo terminal and get a new one), and avoids a weird hand-wave of replacement items just spawning in. Having said all that; the best solution - imo - is the one which we are currently using: adminhelp if your objective is unachievable and the admins will find something that works for you.

Okay, I really like this one. Would still be powerful while also being interesting, and perhaps risky to use.

Another possible idea, as the name implies Flagellant robes, the user should have to deal with some other negative effect than just increased damage, maybe a passive health drain that grows if you don't commit self harm of some sort? Another idea, the armor could inverse the slowdown at low health, so instead of being super slow and easy to hit, you become speed.