osimons wrote: > My reason is to make it easier for me and everyone else to contribute > and help out. It is to make it easier to move new features into Trac > in a contained manner. It is to make it easy for new developers to > come in and take responsibility for individual modules within Trac > without needing to know all there is to know about all parts. The > larger picture is saved for a few people like you and Remy that can > with confidence make changes in all parts of Trac.
Thanks for the explanation, I finally understood your motivations. Yes, it took me a long time, but I did get there in the end :) The two motivations are partly conflicting, but probably not as much as it seems. While I agree that an all-shared structure will require a longer learning curve for contributors to *make changes* to the infrastructure, it should make it easier to *use* the infrastructure, and to use the gained knowledge in a different context. For example, if I have learned how to use the wiki model object, I would then know how to use (at least the common parts of) ticket model object as well. Trac's component architecture is a good example of a complicated infrastructure that is easy to use. It took me several months until I fully understood how it worked and was able to make changes to it. But it must have taken me less than an hour to understand how to use it, and I didn't need to know more for a long time. I was in the "new contributor" situation two years ago, and one thing that gave me difficulties was the heterogeneity in core when doing the same thing in different modules. For example, why does Ticket raise an exception if a ticket doesn't exist, but WikiPage doesn't (and I have to check .exists)? Now, consistency can certainly be achieved without an all-shared structure, but I think the latter makes it easier to achieve. I'm happy to finally understand both views, and I hope we can find a balance between low entry barrier and maintainability. -- Remy
signature.asc
Description: OpenPGP digital signature
