Leaderboard

Preface: This is not really a "suggestion" as of such, more a problem the community is concerned about. Since there is no real place for such a public discussion about this specific topic, I have stolen the suggestion forum for it. I want to make it crystal clear right here that this is NOT intended to bring up any ill-will towards the staff team, and we all agree that the work they do as volunteers is massively appreciated. Everyone has a life, we don't expect you to full-time care for Paradise. However, some of these points do involve asking hard questions to staff, and we want a civil but open discussion about them. The issue at hand: So, what's this all about? Why am I reading this forum thread? Well, if you mosey on over to the Paradise github, you will notice we are sat at about 200 active PRs. This number has been slowly climbing over the past few months and is starting to reach an unmanageable backlog. Why is this a problem? Surely 200 PRs is good since people are actively contributing! Well, yes and no. It's great to see active development and people taking part, but unfortunately we currently have more active development going on than staff are handling, leading to the increase in PRs that are sat there stale. We have a LARGE number of PRs that have been sat stale (or unmerged) for many months, and a handful over a year old! This puts people off contributing, it makes it stressful to have to maintain months old PRs with no feedback on where/why they are not moving anywhere, and quite franlky means the game is not getting as much love as it should from a coding standpoint. What is the cause of the problem? Well, quite frankly, this is what this thread is here to discuss. It's not entirely clear why things are the way they are, or why they are not being resolved. Factors we are aware of: Heads of Staff currently have to actively approve any non-fix/refactor PR. If a PR gets overlooked or no votes, it just sits there forever. (See: https://github.com/ParadiseSS13/Paradise/pull/15139) Unfortunately, it has become clear that heads are not really able to give the time to sort through our massive PR backlog, with approvals being sporadic at best. Now yes, headmins are busy and we appreciate all the work they do in other sections, but with this issue ongoing for over 6 months, it's clear the situation is NOT going to resolve itself by being left as-is. "Stale" review requests. These happen when a code change is suggested by a maintainer, implemented, but the maintainer does not re-review the code. This issue sort of ties into the lack of active maintainers, with @AffectedArc07 literally carrying the maint role singlehandedly for all intents and purposes. (See: https://github.com/ParadiseSS13/Paradise/pull/15404) PR limbo. PR limbo happens when a PR is objected to by one person, but does not get any further approvals. This is also linked to both above issues. PRs like this just drift towards the back page and are not tackled or looked at. So they just sit there. (See: https://github.com/ParadiseSS13/Paradise/pull/15445) Stale PRs. Stale PRs are ones that have not been updated in a long time, and are just sat there. Other codebases handle these by allowing maints to close them at their discresion, however we seem to just let them sit there forever. (See: https://github.com/ParadiseSS13/Paradise/pull/15442) So, how do we fix it? Well, this is the difficult part. It requires a lot of change somewhere, and I'm not sure where to start tackling it. This is why an open discussion with the community regarding WHY these issues have been allowed to creep up, and HOW the staff heads are planning to resolve the issues. Things I can think of that might alleviate the issues somewhat: More ACTIVE maintainers. We appreciate the work put in by all our maintainers, and we don't want them to feel this is an attack. But currently, AA is the only maint actually doing anything remotely maint-like. He is doing everything and it is, no offense to him, too much for one person to stay sane and handle. Allow heads to object, but remove the requirement for their explicit approval on feature PRs. Let the good judgement of the maintainers (people who are familiar with the game and have a good sense of what will help or not) carry the code, and the heads can step in if they feel something is going to cause issues. Be more aggressive in closing stale PRs. Add a time-limit to review requests, if someone has been requested for a review and has not done so in months, their review should no longer be a hard requirement. Be more active in discussions regarding PRs in PR limbo, try to actively resolve them instead of just sweeping it under the rug and letting them accumulate in the background. These are just a few solutions I can think of. Please, community, share anything you feel is relevant. Lastly, we just need MORE involvement from the heads in the current system, and we should not let stale reviews/objections hold up the whole PR system. @Kyet @necaladun @Dumbdumn5 I'm pinging you three here specifically, because I want each of you to please share with us your thoughts on why things have gone the way they have, and how you feel we can solve the issues.

Goal - Send X amount of power back to CC Setup method Clear a large area on lavaland. And place down drills a distance apart from each other, and activate them. These drills could be orderable from cargo or the machine boards orderable and require science to build them? These drills would then start a timer until they complete. During this time, they would disturb the local wildlife. Hoards of lavaland fauna would attempt to attack the drills, and destroy them. It would be the miners and engineers jobs to keep the machines defended and repaired with nanopaste. After the drills have completed drilling, pumps would be placed over the drill holes. These pumps would pump plasma deep underground superheating it, and producing power. This power would be routed into a “power beamer” of sorts, which would blast this concentrated energy back to CC for cargo points. The power beamer’s machine board would be ordered from CC then constructed using high tier science parts. Balancing The more holes you drill, the more power you make, at the cost of disturbing the wildlife each time. Drilling a new hole creates a massive surge of mobs to fight, maintaining a power plant would create a small trickle of mobs. This means that a few powerplants are easy to maintain, however they will complete the goal slowly. Setting up lots of power plants produces more power however you might get overwhelmed with mobs. New lavaland fauna The burrower. A snake like creature that lives underground. Rarely surfaces, unless there is an earthquake or a disturbance in the ground… such as drilling into it. They don’t “move” instead they pop up out of the ground then dig back under, getting slowly closer to their target. They do high damage, however they have low health so you have to shoot them in the brief periods in which they surface. Why is it good for the game? It adds more variety to rounds, giving miners and engineers more to do. Also, @AffectedArc07 wants his argent. Rewards and such are up for discussion.

Hey, good thread. I've only just starting getting involved on the contributing side of Paradise, but I quickly noticed the backlog. Whenever I would ask on the discord what's up, the answer from others has always been some variation of "heads aren't approving things." which it seems is not the full story based on this thread. I wonder if more transparency in the process would help. As a new contributor, it would be nice to know: 1. What the process actually is. I had to learn about the github approval process by asking around and I'm still not totally clear on how it works. I understand that heads vote to approve features, but I don't know much beyond that. As far as I know the github merge policy isn't actually documented anywhere? 2. Transparency on the head votes/approvals. I often see Kyet on github very helpfully approve or object in a comment, but I am never sure what that means. Is that him voting for it? Does that mean it's approved to be merged by all the heads? What else needs to be done? Do the other heads need to vote as well? 3. A clear indicator of when the baton has been passed to the next stage. Maybe this can be accomplished with PR tags or comments, but its not clear to me who "has the baton" on most PRs. Is it awaiting head review? Is approved and awaiting code review? Does it need changes? Has it been objected to? It would be nice to know clearly what stage a PR is in. Sometimes github comments show this, but other times I hear through discord that the story is different on certain PRs. For example, I got a PM from Neca saying he voted for one of my PRs (thank you!), but based on what's in github I don't know what the other heads think, if it has been approved, if they need something more from me, etc. 4. Is it okay to PM people about github stuff? I imagine staff get pinged all the time about random stuff. I don't want to add unnecessarily to the noise, but I'd also like to know how staff/heads/maintainers feel about discord PMs on github issues. Is it okay to ask what the status is or would you guys prefer we keep things in github comments? Is there already too much noise for you guys or is it okay? The impression I get from discord is that many contributors feel their work is being ignored, but maybe that's not the case. Some of the suggestions above might help people see "Hey, we're looking at it, we just haven't been able to move it forward yet." Or, at least it will help people understand what stage their PR is in. Related to maintainers: Like I said, I'm new to the contributor side of things but I've already seen what a madman AA07 is and the work he puts in. A big thank you to everyone who contributes and maintains the github. It's often thankless work and I'm sorry you guys have had to deal with any abuse at all. You make the game possible and we players really appreciate it! It's unfortunate that angry players are usually louder. I don't know what the process is for this, but is there any way we can make it easier for maintainers? Are there any PR reviewers that can step into the role of trial maintainer? Are there any contributors that are ready to step into the PR reviewer role? Is there anything the average player/contributor can do to make their lives easier? Lastly, big thank you to the staff here. Paradise is a really amazing server and the work you guys put in has made something special in SS13 history IMO.

So as far as head approval goes - not an issue. We've approved about 100 or so. That's not an issue at all. Really, there's one perfect solution to this: We chain up the maints in a basement on an IV drip of Amphetamines. But supposedly that's 'illegal' and 'unethical'. It worked great with Ponies tbh. Look, frankly I'd love for the maints to be more active. I'd love more hours out of them. If you read this - please be more active and do more work for 0 pay and negative respect. But in the end, this is a volunteer project. The biggest thing that they've told me would help with this, is for the contributors and community to stop treating them like shit. Every. Single. Maint. Ever. Has complained to me about how toxic the github is, and how much they hate 'the communities' reaction to them moving rapidly. If you want more shit done, give us the permission to do move quickly on things without the abuse, toxicity, and general bullshit we have to endure from it.

That's fair yeah. But I don't think anyone besides the Heads or Maintainers actually know the maintainer qualifications. The only solid information I've heard is "Be popular with the maintainers". Other than that, I have no idea what the requirements are, what knowledge you need, or how the hiring process is done. As far as I know, none of this has ever been shared with contributors/PRRs, but If it has, I'd love to hear it.

While it would be nice to have the current maintainers suddenly stop being busy and have free time to maintain the codebase, that's a silly expectation. IRL comes before SS13. But, The obvious solution is to hire more maintainers to spread out the work load (S34N already mentioned this). Then, in event some of them do get busy, the entire GitHub doesn't screech to a halt, and people wouldn't get frustrated as much, because things would be flowing. We have volunteers that want to do this, but it seems there is 0 care or effort into making this happen. Overall good thread, you basically hit the nail on the head with all the issues we're facing. This stuff has been going on for years, so I've basically given up trying to talk or do anything about it, because it's usually brushed aside. I've already highlighted the biggest issue I think we have with the paragraph above. All I can do is hope things change.

The Premise The Syndicate has hijacked a military grade cruiser capable of hauling a large amount of weapons and operatives, they plan on testing out their new toy on an NT station. The crew must defend their station while destroying the cruiser's experimental reactor and or damaging a % amount of the cruiser based on server pop. Or in event of being overwhelmed, escaping with as many crewmembers as they can carry. A Syndicate major victory is achieved by exterminating a % population of the station based on current server pop, a minor victory can be achieved by forcing the crew to abandon the station via the escape shuttle. A Crew major victory can be achieved by destroying the cruiser's experimental reactor core, a minor victory can be achieved by causing major structural damage to the cruiser but not destroying it via a reactor detonation. Syndicate Operatives will appear in spawn waves at somewhat regular intervals on their cruiser which is physically located on one of the more desolate Z levels such as Z7, they will have access to an expanded uplink compared to a standard traitor but less than a standard nuclear operative. The operatives will assault via drop pods and the crew will be given a shuttle they can use to launch assaults on the cruiser. The Goal This new potential gamemode would add a more "slow burn" style of nukies that allows further relevance of departments such as Science, Mining, Engineering, and other departments that currently are basically invalidated by the nature of War Ops and regular nukies as a whole. A prolonged siege style gamemode gives more purpose to station equipment such as the BSA or toxins bombs as well as the wide variety of weaponry available to the crew that often isn't used due to the length that comes in its creation. It also offers a new variation of the Crew V X antag as the crew in order to win has to take the offensive to a place that isn't their home turf in order to succeed. It is also something we don't currently have as a gamemode. The Work The actual amount of work sprite and code wise likely wouldn't be too large, a lot of the concept relies on already existing assets that just need to be put together into a structured gamemode and a degree of mapping to design the syndicate cruiser. Likely the only things that would be entirely new would be the syndicate cruiser's reactor, the altered uplink and the new shuttle dock for the boarding shuttle.

I am pretty sure by "raging" he just meant the property of raging mages where its not 1 wizard but rather waves of wizards, which he implies here - waves of "nukies"

Name: Xion Robinson Age: 36 DOB: 17/9/2530 Gender: Transgender Female Race: Human Ethnicity: Sol, Cuban Blood Type: A+ General Occupational Role(s): Bartender, Security Officer, Detective, Captain Biography: Little is known about Xion prior to her arrival at Nanotrasen, but she is heavily scarred along the chest and extremities. She is rumoured to have been involved with various crime syndicates prior to her contracting with NT at the age of 30; police records have recorded evidence of crimes including armed robbery and assault, but this was not known prior to her employment. Generally very friendly to most people, but has a short fuse and will explode violently upon those who mess with her. Despite her shortcomings, she has been heavily profitable for the management of the Cyberiad, and continues to maintain a level of efficiency that outweighs her outbursts. As for medical status, Xion is a chronic alcoholic, drinking just enough to avoid blatant drunkenness; she has had a cybernetic liver installed to replace her failing organic liver, and this cybernetic soon had to be replaced as well. She is also addicted to nicotine, and regularly smokes several packs of cigarettes throughout the shift. She has a Xion Manufacturing (unrelated) cybernetic left arm attached, as her arm was severed and went unrecovered for reattachment, following an explosion during regular security operations. Valuable, if somewhat unstable contributor to Nanotrasen, and a dedicated sister-in-arms who will sacrifice her own life for her compatriots.

Probably a good portion of my adminhelps over the last year or so have been asking if an admin could let me know what x variable is set to, and I'm sure I'm not the only one who's been sending these. Having the ability to see (and set) variables is an incredibly useful tool as a coder, really only matched by proc calling. Unfortunately, unless you have admin permssions or you spam ahelps during a testmerge, the ability for non-admins (PRRs included) to debug objects and behaviours on the live server is severely limited. Add to that the number of issues which seemingly choose not to happen at all in test servers or are limited by population, and you've got a pretty high number of bugs and runtimes which aren't being fixed or even detected. Any admins experienced with DM code will be able to avoid this issue of course, and potentially even create a PR to fix the issue right on the spot. 'Codermins' like this though are very much the minority, and while many admins know how to edit variables and debug to some degree, tracking down the source of a runtime or a reference error can sometimes be a whole different process entirely. I propose that we stealborrow PR #30463 from /tg/station, which allows admins to grant a read-only version of a datum's VV panel to a player of their choice. There are likely still bugs in my quick test port, and I know there's bound to be some variables that need to stay admin only, but I've attached a video below to demonstrate the feature. The potential benefits of this really are countless. Assuming it can be made as airtight as possible so as to not allow a greytider to edit someone's ckey out of existence, this would allow PR authors to have much greater insight into how things interact with players during a testmerge. Along with the obvious debugging capabilities. The current version of this still requires an admin to show it to you, which is around the same level of effort as just reporting back with the value of a variable, but I'm hoping that if this idea gets any traction that the read-only version can be given to PR Reviewers and possibly Mentors under limited conditions. (Possibly with extended permissions to allow for navigating nested objects, but that can come later.) As I said, I already have the main part of the code ready to go, but I thought that since this is very much an admin-centric idea that I would wait for any feedback from staff before submitting it fully. Jv3Ka78C2A.mp4

You should totally have it need filters that are necessary for it to produce power. THEN, have it be a traitor objective to sabotage the aforementioned filters; could totally get S. Hayden from the Syndicate Communique to say, "We are only temporarily disabling the towers; you need to remove each lens individually. Carefully release the hinges..."

god fucking damnit steve

This has been added to the to do list.