The following is a bit of a résumé on the 2.8 project from my POV. There are many lessons to be learned from it I think.
Am Fr., 5. Juli 2019 um 16:54 Uhr schrieb Brecht Van Lommel <brechtvanlommel @gmail.com>: > I think the main issue recently was that for the first half of the 2.8 > project, many changes were made without well-defined use cases and > design, and much code was left incomplete or broken. This left the > second half of the project with the difficult task of solving much > technical debt, with little time left for anything else. > I definitely agree on the issue of technical debt, not so much on missing use cases and design. At least for the projects I was involved in (includes projects run by others where I helped with feedback/advice), lots of effort was put into requirements, specification and design considerations. Dalai and Ton were really pushy on that. IMHO the issue is that some of these designs didn't work well in practise. In the first half, many bigger projects were tackled, and I think those are the ones causing problems now. They kept dragging on for long periods. Many of them were 'big picture' ones and depended on other projects to reach full potential (layers, collections, workspaces, workflow oriented viewports, etc.). I guess the whole "workflow" thing was a huge beast but lacking user involvement. Not saying there wasn't any, but not in a broader sense. At the time, to the "outside world" 2.8 apparently seemed like Eevee + some other WIP stuff nobody understands or uses yet. Despite efforts to communicate designs well. There was a big lack of user feedback. Designs looked awesome on paper (at least to some), but turned out to be faulty later. It's selfish to say so, but I saw this coming. The first half of the 2.8 project, I wasn't at all happy with the direction it was taking. For me the Code Quest + usage of 2.8 in Spring production was the turning point, marking the second half of the 2.8 project. Suddenly the project turned into a hugely dynamic one with very visible results. Users became part of the development loop. We went back to what has always worked best for Blender. However, there was so much dynamics, that I'm afraid we'll find lots of longer term technical debt from it too. There's always a trade off, although I think it is worth it in this case. Another issue is devs losing motivation after projects dragged on with mentioned issues. Maybe this is mostly about me again - for many reasons (not being able to push 2.8 into a for my opinion better direction was a big part of it) I lost motivation and eventually left the project. And with that I also left big technical debt... With long iteration loops we run into the risk of this happening more. > We plan to go to an iterative approach with regular releases, and it's > not easy to predict how that will go after two years of a different > model. There is a risk of getting bogged down in bug fixing and small > changes, without time or confidence to finish bigger things. > > Developers should be given time to tackle those bigger projects and > refactors. On the other hand, those projects then also have to be done > in a more disciplined way. That means splitting up projects into > smaller steps. Fully going through the design, implementation, > stabilization and documentation for each step. Developers should be > encouraged to pace themselves so they can take the time to do projects > well, but at the same time keep delivering finished steps even if they > are small, and getting user feedback early. > I guess the big lesson to be learned from all this is how important short iteration loops are. Get visible results quickly, get user feedback and keep evaluating and adjusting requirements, specifications and designs. But don't neglect the code quality (too much), that'll slow you down later. Short release cycles enforce this a bit so I like the idea of getting back to them. But indeed, we need these timeouts to work on big projects. Those can be developed in short iteration cycles as well though. In other words: We need more Scrum. Not a business variant for micromanagement and short term success, but what it was initially created for: A framework for developers to manage themselves for both short and long term agility. I didn't go into other aspects yet, like developer documentation or review process. Would be happy to cover this with a bit more time at hand ;) Glad there's someone asking for feeback on the dev process! > I have a document with more practical suggestions here: > > https://docs.google.com/document/d/1gxuBv6aeZjKgzMQmGYdaERKbd7VnllSa9s_ejl2hMGo/ > > > > > > > > > > > On Thu, Jul 4, 2019 at 3:38 PM Nathan Letwory <[email protected]> > wrote: > > > > Hey all, > > > > As you all may know by now I've been asked to help coordinate and manage > > the Blender development. > > > > To get a better understanding of what these days is going on, and to > > prevent me from just acting through my personal preferences, I'd like to > > hear from the blender developer community how they see the current dev > > process. > > > > I'm most interested in finding out how devs perceive the process: what > goes > > well, and even more so what causes trouble. > > > > An open discussion by anyone on this topic is of course welcome, but I'd > > like (and also a bit expect) input at least from those who are listed on > > the Modules [1] page. > > > > Cheers! > > > > /Nathan 'jesterKing' Letwory > > > > [1] https://wiki.blender.org/wiki/Modules > > _______________________________________________ > > Bf-committers mailing list > > [email protected] > > https://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ > Bf-committers mailing list > [email protected] > https://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] https://lists.blender.org/mailman/listinfo/bf-committers
