Management of the config and the role of policy discussion in config in 2025

[subject217]

Hi there, I couldn't think of a better place to ask this question. In the past, as I understand it, the /tg/station config was private, and it was generally managed by the head admins. Discussions on config changes have been confined to Policy Discussion, which is ostensibly a place for discussing the rules.

Now, post MSOvering, the config is publicly available on Github. If you look, you'll see that PRs have already been made to this repo and they have been merged. Yesterday Kinnebian's PR changing lowpop antags was merged by the current head admins. I think this is a great change, but it begs the question of how we discuss this kind of stuff. As far as I'm aware discussion of this repo was limited to a headmin election thread, and I could find very little player discussion about the specific proposed changes.

Should we have a new subforum specifically for config changes? Should we have a forum post for every PR that is made to this repo, at least if it has player facing consequences? Does anyone besides the head admins have the authority to determine what is managed on this repo? I'd like to hear what people who aren't running as headmin candidates think about this.

At the very least, I think it would be good to have some documentation in a more permanent place about the existence of the config repo, who's responsibility it is, and what the PR process for it is.

[DrAmazing343]

As the person who Merged the PR, and who will very soon be out of office but with Big Opinions— I do think that config changes should by and large be on the Policy Discussion board. The intent of the config changes merged, however, were in an attempt to return closer to our config pre-MSOver.

We entirely lost the config we had prior to the meltdown and that is why some players have been reporting Dynamic acting fuckin' insane. We've been off and on working on restoring it to how it was before, but now that it's more or less public, I'd happily engage with players on what sort of changes they'd like to see, as the Players doing the Playing of the Game.

Still, in all honesty, this will very shortly be something those incoming headmin candidates will have to grapple with. I can only hope they share the vision.

[subject217]

One other noteworthy thing, we have two auditorium threads that are specifically for disclosing config changes, which have not been used since November of last year.

viewtopic.php?t=14828

viewtopic.php?t=35296

Now obviously, a lot has happened, and as Drama Zing says, we don't actually have that old config anymore, so it's not surprising that they have gone unused since. I think it's quite important to disclose changes, but we don't necessarily need these threads with the repo. Would people still find it useful to post changes in them?

[Cobby]

Whats more realistic, a player reading the github changelog or a player reading the forum?

Funny enough youre better off putting those as a bot in a discord channel or something if you think people cared enough, otherwise id just assume let people navigate the github which in turn steps them into how to do it for the code.

[kinnebian]

Relevant, I actually had a solution for this issue In my headmin thread I'd like to go forward with even if I dont win this.

Update: I've actually put some thought into potentially a psuedo newsletter for the tgcord. I've made a format, and I'd be happy to run it. Even If I dont become headmin, this is something I'd like to push for.
heres the example formatting:

► Show Spoiler

I think something like this would bring visibility to the config changes [amongst other things in the newsletter that are typically exclusively to forums] and bring them onto the discord, in its own channel.

[Jacquerel]

We have a "github discussion" bot which redirects commenters in tagged PRs to talk about a PR in a discord thread instead of on Github. Frankly, I don't much like this feature for code PRs because I don't think Discord is a godo place for these discussions.
...but for policy PRs it might be a good idea. Or alternately, one which automatically posts a thread in this subforum.

More people for sure use Discord than the forums, but I think Discord conversations about these topics are way harder to follow and invite less thought.

[Cobby]

More people for sure use Discord than the forums, but I think Discord conversations about these topics are way harder to follow and invite less thought.

Sorry, I was saying put the changelog portions as the discord bot since I think most ppl care about the results instead of the entire discussion (if they care at all), the actual discussion prior that makes or break it I feel is still appropriate for Policy Discussion.

I havent looked into how the PR process is managed for config changes, but the discussion needs to happen on a singular platform so if it isnt on github then just make sure the github discussions are closed and require the thread be made prior to PRing.

[Jacquerel]

More people for sure use Discord than the forums, but I think Discord conversations about these topics are way harder to follow and invite less thought.

Sorry, I was saying put the changelog portions as the discord bot since I think most ppl care about the results instead of the entire discussion (if they care at all), the actual discussion prior that makes or break it I feel is still appropriate for Policy Discussion.

I havent looked into how the PR process is managed for config changes, but the discussion needs to happen on a singular platform so if it isnt on github then just make sure the github discussions are closed and require the thread be made prior to PRing.

Oh this wasn't a reply to you, I was talking about the existing interface we already have for the code repo just sort of separately because it seemed relevant.

I do think we should also have a changelog channel in Discord that basically mirrors the in-game one though, and we could also do this for policy PRs.

[Timberpoes]

The incoming headmin term have been convinced to not use Github to discuss server config changes. This probably means that you're unlikely to get config change approval outside of making a policy thread, unless it's to correct an incorrect config entry, update the config when the codebase adds new options or something clerical like that.

They have decided to use PRs instead of direct commits to try and retain some sort of sane changelog. As a maintainer-headmin I hope future terms adopt this practice if we have to keep using this system.

This won't be documented anywhere as future headmin teams will do whatever they want and on their heads be it if they decide to change established norms and fuck the whole thing up. This is the right of all headmins, inalienable and gifted to them not by God but by a higher power still, being voted in via Democracy.