Sorry for the trouble here. We just deployed a change that should make this happen less often, please let us know if you continue to experience issues.

Apologies for the lengthy delay. Today we increased this limit from 100 to 400.

@mooware the MIME-Version header bug should be fixed, thanks for letting us know! I also checked our DKIM configuration and couldn't find any issues, so you may want to investigate that on your end.

@Kounine the keys were distributed yesterday via the messages function on the website.

Hello, you can open up a support ticket at /support/tickets. Tickets are answered in roughly the order they were received. Please do note that some members of our team are traveling (at AGDQ) and so responses may be slightly delayed this week.

Very cool - I watched this with family over the holidays, everyone loved it!

@Liv thanks for the report, you're correct in that the subcategory tabs aren't behaving as they previously did. This is a new bug (caused by some other under-the-covers changes we're testing) and will be resolved soon - apologies for the inconvenience!

@andresfgp13 sorry about this, we're deploying a fix now.

Thank you for the kind words, it means a lot!

This should be fixed now, sorry again for the trouble!

Sorry about this, we're investigating.

@VyPr thanks for asking!

I don't think we'll be able to share a public roadmap in the near future.

We maintain a big backlog of new features, bug fixes, and other improvements, but the actual development work gets scheduled very dynamically. For instance, right now we're working on a major new feature launch due in October, but are also fixing bugs every day. The major new feature isn't ready to be announced, and it's not unusual for a bug to be identified, scheduled, and fixed in the same day. We're a small team and prefer to operate with as little overhead (read: as much flexibility) as possible, and maintaining a public roadmap would both set unrealistic expectations and slow down development.

With all of that said, we do plan to be more consistent in providing site updates (via site news) where appropriate.

In order to reassure them does SRC support rollbacks for games/boards/categories?

We don't currently expose any rollback functionality to game moderators. We actually just discussed this internally this morning, and it's on our roadmap for 2024, but can't I offer a solution for this today - sorry!

We generally don't recommend that anyone share API keys, but it's ultimately a matter of what the game moderators are comfortable with.

@ShikenNuggets is correct on all counts! You might ask the game moderators to add you as a moderator to perform the migration.

@C4THR33N I stand corrected, sorry for the confusion! You will indeed need a moderator API token to set the "players" field.

Hello and thanks for considering a migration to SRC! I can provide some clarity here:

• You should be able to accomplish your goal using the API (specifically the POST /v1/runs endpoint)
• You do not need authentication tokens from players in order to submit runs on their behalf.
• You can use any normal user authentication token, including your own.
• The user who submits the runs (including via the API) will be noted as the "submitter" of those runs, and have their name displayed as such on the run pages.
• Players in runs are specified within the JSON "players" field, and they can be specified in two forms: as users (for which you'll specify a SRC user id) or as guests (specify a name). I'd recommend finding existing SRC accounts for users in question rather than submitting by name wherever possible. With that said, game moderators have the ability to edit the runs and update these later.

You can find more details about run submission via the API in the POST /v1/runs documentation.

@Act_ @KilleDragon we posted guidelines for what would make a story newsworthy (both in this news post, as well as the "Submit community news" page), but do not have a rigid set of acceptance criteria.

For now it's a judgement call by SRC staff based on a variety of factors (appeal of story, quality and timeliness of submission, etc). We'll iterate on that approach as necessary, and it will be easier to intuit whether or not a story would get approved based on examples once we start publishing them.

This bug should now be fixed, sorry for the inconvenience!

Thanks for the feedback here! I do want to push back a bit on the notion that we're looking for free labor - that's not the purpose of community news. Let me elaborate...

SRC serves as a platform for tens of thousands of individual game communities, but what happens inside of a game often stays there, never reaching a broader audience of gamers who may be interested. This feels like a missed opportunity, and I think SRC has both the ability and imperative to celebrate these achievements and promote them to a larger audience.

We have paid staff (including myself, some names you probably know, and some you probably don't), but it's just not possible for us to capture everything - the surface area is too large, and we all live within our individual bubbles. That's where community news comes in - it's a big net and funnel to promote a wide variety of communities and ultimately surface interesting stories that would otherwise be missed.

Paid SRC staff members will both be writing original stories, as well as reviewing/editing community submissions. Community news will not decrease our costs, but actually increase them.

My long-term goal is that the SRC homepage becomes a valuable resource for staying informed, both with the games/users you've chosen to follow, as well as a high-level overview of other stories that can broaden our perspectives and expose us to new things we'll enjoy.