A release procedure for changes
-
This one is pretty simple and not really an in-game feature, more of an organizational thing. Requires no coding and virtually no additional effort of any kind from the devs, really.
Recently @artch wrote here that they could use a dedicated community manager, but I think it's not really needed here. Communication about any change that may break a bot, should be:
- Done upfront, with sufficient time before the message and deployment to adjust the code
- Done on forums, twitter and slack #announcement
- Recorded in a public changelog
Now lets talk about the real cost of it.
- is free - the amount of tweets, forum posts and slack messages will stay exactly the same (though after this the changes will be communicated through official channels before deployment and not two days after)
- is already happening usually, but it's not reliable. Costs seconds to do, but having a mindset of communicating things through all official channels will make it easier. No need to decide what gets communicated where anymore! Once the text is written, it's a 2 minute procedure to send it everywhere, but it makes sure people see it.
- Putting the a date and the same message in a file that is published somewhere is also not a whole lot of work and it would let people catch up, if they take a pause from the game for a few months.
Even if it does slow down development of screeps, 2 min per week is worth it. I'm not going to calculate the percentage of development power that will need to be sacrificed to do this well, because this proposition is not adding the full two minutes per week - communication with the community is already on the task list - this thread is about rearranging things slightly, so that people who only play on the weekend and those who don't follow forum threads, are not surprised by their bot stopping due to unexpected changes.
-
These are all good ideas!
1,2 - This is a great suggestion, and actually a well-known best practice. We always do that in case of breaking changes, and also do our best in all other cases. Sometimes it goes wrong like in the generatePixel case, but that situation is a bit unique: initially we started a 2-weeks notice, then changed the mechanic due to the community discussion, but the schedule had to be the same because of other factors involved like seasonal development, upcoming winter sale on steam, developers vacation periods, etc. We can't explain everything in all the details (not because it's confidential but simply because it's unneccesary), but we always do our best to notify everyone in advance.
That being said, even the updated generatePixel behavior was announced 48 hours in advance on both forum and Slack. We probably should have posted it on Twitter as well, but I mistakenly concluded everyone would see it on either Slack or forum.
By the way, the most important news are also announced on Reddit, Facebook, and Steam as well. Some breaking changes (like
StoreAPI) also were emailed to all registered users.3 - We tried to do that before (veterans of Screeps may remember our blog, old Support Center, and changelog file on GitHub), but it all was suboptimal. Twitter, Slack, News & Announcement forum receive much more attention and have better abilities to engage community into the discussion.
-
would be there an option to have another link in hamburger menu, with red-dot when there would be an new update in PatchNotes ?
-
@gadjung Yeah, this is a good idea too, we should research how to integrate the game client and the forum in this regard. Added to the backlog.
-
@artch, is there any way that when changes or decisions are made that affect the community, a quick paragraph or two of explanation could be included? I feel like the most recent post, where you explained the pixel generation, was perfect and exactly what the community was initially asking for.
This seems to be a trend that I feel yall could easily fix. I remember when the community PR for detecting novice/respawn zones, was closed without comment. It took the community multiple days of asking for an explanation. Again, yall posted a well laid out explanation where you pointed out that the way the PR did it only allowed for detecting them if the bot had vision, but you wanted to implement it without vision. Yall wanted to take the time to implement it correctly, critiqued it, pointed out a flaw, and explained why.
The why is what the community desires. I feel like many of us deal with knee jerk decisions at work, and if we see something with the appearance of a similar situation in a game, it adds a level of frustration that makes the game seem less fun. A quick 5 minutes to add a paragraph could save a great deal of grief for both you devs and the community.
-
A quick 5 minutes to add a paragraph could save a great deal of grief for both you devs and the community.
That post took me 1.5 hours to formulate and write. Remember, not a native speaker here. Also, it's not always easy to predict what is not clear in what is posted already. I have posted some explanation from the beginning, someone misinterpret it. Then I posted more explanation, but someone said it contradicts the first one. Then we changed the mechanic, explained our stance towards some of the ideas, but someone told it's not enough. The misunderstanding continued to grow gradually, not jumped up from the start. When I realized what's the root cause, I immediatelly took the time to explain the key points. But in the beginning of the conversation it was not clear. We honestly believed this simple balancing change is obvious for everyone and didn't require any explanation at all, this is why we simply wrote a joke about "high-energy continuum pixel etc."
We do our best to explain everything, but it takes time, so we ask you to be patient and not demand everything right here right now. And remember the language barrier, it really takes effort from our side.
-
@artch so you guys are looking for a native English speaker to volunteer to be community manager?
-
@rhef <- this guy gets it! That would be so helpful! (also evidently that one guy didn't see what you did in that other thread before you undid it, so you're in the clear lol)
-
A small example of a missed opportunity was the bugfix that went out yesterday for seasonal regarding collectors being walkable. Most of us assumed that was intended, and a few wrote code to make use of it (with guards, etc..) so when the "fix" was put in it broke some code and wasn't discovered until o4 commented on slack.
-
This thing @Shibdib mentioned is exactly the point of my point "zero" and "1" - some people can usually only see notifications and adjust their codebases over the weekend. Even a small change can break their code, even a change that relies on undocumented behavior (global ticks resets being rare is not documented nor guaranteed, yet all high-end implementations rely on it heavily, so lets not say that changing it drastically without notice would be fine).
Would releasing things on Mondays be so bad? Especially small ones like generatePixel (which was running at 5k for years without problems, change can be rolled back easily, 4 days would not make much difference) and walkable seasonal collectors (not really a gamebreaking flaw, even if it stayed like this for the entire season, I think we could endure). Those should be able to wait a couple of days on a branch.
If you don't want to create a new changelog format, some good people have standardized it already. Thanks to standard there are some opensource tools to parse the changelog styled this way, in case it needs to be reformatted or something.
Finally, if you'd call out to the community asking for someone to volounteer to translate explanations from Russian, someone might actually raise their hand and if language barrier is the problem, then that woud save you a lot of time. Doesn't have to be native, just needs to read Russian and write English well enough.
-
@rhef said in A release procedure for changes:
which was running at 5k for years without problems
I assume that's hyperbole? Pixels were launched (exactly) 6 months ago!
I agree with the general sentiment though IMO most changes have been fairly well telegraphed recently.
-
some people can usually only see notifications and adjust their codebases over the weekend
Absolutely. We generally give 1-2 weeks notice for all changes. This is why we started a two weeks notice for the generatePixel change. Unfortunately, even after adapting it we had to follow the same schedule, because this December is a very special period - two steam sales, season start, vacations, etc. I don't think we have to take this situation as indicator. If we're making generalized conclusions here, let's analyze all old updates and how we implemented them in the past.
-
I think most would just be happy with a blog post with change notes. Don't need big announcements for everything.
-
