On Sat, Aug 15, 2015 at 3:15 PM, Jacob Merrill <[email protected]> wrote:
> I think step 1 in any proposal for change, > > we need a new 'map'/flow diagram of the current system, > > any proposed change would be a editied version of this map, > Reminds me of the blender 2.03 book :) But that was a map of the externals, not internals. > I have steadily been trying to digest commits, and understand > what everything does, could steps be taken to refactor blender > to make it be more approachable for coders in their blender infancy? > This is more about diving into the code. Which is a separate issue but worth talking about. I don't think making code more beginner friendly should be a goal. A beginner is just someone who's not an expert yet. Good refactoring makes it better for any coder, not just new people. could there be 1 day a month we set aside to helping new developers get > into the flow of commiting? > Most years we have GSoC for this, which allows a more hands-on introduction for a few new coders. I was new to blender's code and development work flow 5 years ago. By now I'm really comfortable with the parts I care about. The key to getting started is pick one area and learn as much as you can about it. Who wrote this? Who else works on it regularly? Are any parts of this code "dead"/obsolete, so you can skip those and focus on the "live" parts? That's any code base really, not just blender's. Understanding the code as it exists today isn't easy. It's big and has a history. Keeping up with new commits isn't easy since there's so much activity. It's possible though, and I've never gotten the impression that anyone is actively making things harder for new people. Mike Erwin musician, naturalist, pixel pusher, hacker extraordinaire _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
