[{quoted}](name=Maple Nectar,realm=NA,application-id=3ErqAdtq,discussion-id=qgPXfKtQ,comment-id=00030002,timestamp=2018-01-26T04:32:36.379+0000)
You summed it up pretty well, but I'll throw in my two cents from the perspective as one of the team leads.
From a process perspective:
When we're working on a patch, we have about two work weeks to choose our targets, dig into a shit ton of data, come up with a few paperkits, implement said paperkits, test them, get feedback, iterate, test again, finalize iterations, and get in for actual bug testing and localization lock (for things that are changing tooltips and need to be translated). What this usually amounts to is that we have from ~Wednesday afternoon to the following Friday to get our changes through the various development stages and into the next patch. After we lock on the Friday, we have the following Monday/Tuesday for any final power tuning and bug fixing before the entire patch gets "locked" and no more changes can be submitted. From there it goes into extensive bug testing internally, at vendors, and in partner regions to ensure all big bugs have been caught and fixed before we go Live the following Tuesday-Wednesday. This means that from the time we start working on a task, it takes 3 weeks before that change will actually get shipped live (which is one of the factors in it feeling like it takes a long time for things to get changed).
Now, not all of our work is targeted on a 2 week cadence, there are times where we have some larger work on our plates for a few sprints/months before it ships, but the bulk of our work gets run through the rapid two week cadence. When we're already working on a fast schedule, one of the things that can drag down any team in any organisation is having too much work in progress. It's something you need to be hyper aware of, as having too many things on the go at once is likely to lead to a lot of stuff falling through the cracks, or burnout because of people trying to deal with the overhead of each individual piece of work they have on their plate. What this means at Riot is that the specific designer may have 4-5 tasks of varying sizes on their plates for a given patch, and each of those tasks requires investigation, ideation, implementation, playtesting and gathering feedback, iterating based on said feedback, fixing bugs, writing patch notes etc. Anything that bleeds over to the next sprint adds to the overhead they need to manage the following sprint (including adding another testpoint to playtests that are already crowded with changes from all the teams in core gameplay). While breaking things up as you suggest would lead to smoother releases, it also just doesn't scale well in a real world development scenario (that's not intended to sound condescending).
What this means from a product perspective:
One of the things that we try to aim for with our larger changes is offering interesting and compelling gameplay that alters the way players may think about when to pick a specific champion, how to build them, or where they could play them. Things like; what if you could take Nunu bot lane with an Azir or Kayle instead of just in the jungle when you have a hyper scaling adc? Or what if you could take Morgana or Zyra in the jungle if you got autofilled jungle as a support main but your team was entirely physical damage? These types of changes tend to err on the riskier side of the equation because we're trying to balance for a lot of factors. Things like what will this look like in pro play? What about Diamond? Will this be pubstompy in Bronze? Would this be something players find exciting or interesting? The list goes on and on, but at the end of the day, sometimes we have to take our best guess which is informed by the few playtests we get, trust our gut, and go with it. Can this result in us having some releases where we sit back, see the results of a change and think "damnit we did it again". Yep. But does that make me question whether we should have held onto a change for an additional 2 sprints to try and eke out even a tiny bit more value from playtests to give us the confidence in a direction or present tuning? Very very rarely. When all is said and done, the data that we get from our changes being out in the wild for even an hour gives us far more information than we can get from our playtests. This means that we can adjust a champion to be right around where we're happy with a day or two after release as opposed to holding onto them and carrying the overhead cost of managing the task through the various dev stages for another month to get us to the same result (maybe). While people tend to look at them as massive misses on our part (which they are), I'm fine accepting that cost as long as we're willing to own up to it when we do and hotfix them when necessary. At the end of the day as a lead I'm accountable for the results of my team, and if needing to do hotfixes was causing players to churn from the game or completely lose all faith in Riot then I'd definitely revisit this as a philosophy, but as that hasn't materialised so far my tendency is to lean towards iterating quickly as opposed to drawing changes out over a long period of time.
@OP:
To be entirely clear, your thoughts aren't wrong. If we wanted to go for the smoothest releases possible, we could easily adjust to releasing changes the way you suggest (1/4 or 1/2 at a time). The primary benefit there would be we'd have less egregious cases like Nunu crop up, and the primary cost would be that we'd be able to do net fewer changes as we adjust our workload to account for carry over tasks. It could be that the trade-off is worth it, though for now I'm not convinced. In my mind the worst case right now is that we end up having champs like Nunu be strong for a day or two, people get to see them pop off with some fun synergies, and then we get him to a spot we're roughly happy with - which is ideally far better than he was before.
That being said...
One of our hopes with changing our patching cadence to be a large patch followed by a small patch is that we get additional breathing room to work on larger projects rather than trying to bundle everything into a standard patch. By changing our small patches to have significantly fewer changes than what players are currently used to, it grants us significantly more bandwidth to work on the larger term stuff that hopefully has a larger impact on the overall state of League.
Hopefully the above reasoning makes some amount of sense. I have this awful tendency of writing fucking bibles on the boards :P. Let me know if anything needs additional clarity.
had his unstoppable removed. This lowers his skill ceiling and opens up minimal counterplay, but doesn't solve his actual problems.
.
