Ilias Lazaridis wrote: > Within several other open-source projects, I've seen the concept of > "component/subsystem" "leads/owners". > > I have difficulties to identify the relevant component-owner within the > trac project. >
Well, just ask. > Possibly the project should provide a document which mentions the > responsibilities of the trac team members. > That's easily gathered ... using the query facilities of Trac ;) Simply do requests for the component which interests you and group by owner. In addition, this kind of "ownership" tend to vary over time, so a document like that would quickly become obsolete. > Component Owners: > * get the tickets subjecting the component assigned > it's already like that > * delegate tasks to contributors or to themselves > we don't like to delegate ;) > * communicate requirements and requerst to other component owners > * assing subcomponent ownership (e.g. file level) for external > contributors > certainly not, though when someone contributes a piece of original code, we're more likely to accept patches from the original author more easily (e.g. Shun-Ichi Goto for the Image macro, Tim Hatch for the Ranges utility, the PHP tests, etc.) > Subcomponent ownership can be either temporarily (e.g. for a > refactoring or small extension), or long-time (e.g. for active keeping > a file and it's functionality up-to-date). > > Other team members (and the Project Lead) do not 'touch' the > components, but instead pass requirements or change-requests to the > component owner. > > This protects the thinking-flow of the component-owner (e.g. does not > have to deal with introduced code-changes e.g. during a brain-ripening > phase). > We do this a bit differently: in trunk and 0.x-stable we integrate low-risk changes or branches once they're stabilized and we use branches if some kind of "brain-ripening phase" is needed. Even for that, we decided a while ago to _not_ give a strong sense of ownership to those branches, by putting them under a common sandbox, so that everyone can participate (we used to have private sandboxes, but those are not active anymore since this policy changed). > And: this ensures a consisten coding style (e.g. functional form > ComponentOwner A, OO from ComponentOwnerB). > We try to maintain a consistent coding style overall (see TracDev/CodyingStyle) > - > > I think Component Ownership is the best way to manage a project which > becomes larger and larger. > Well, Trac core is not supposed to grow larger and larger, quite to the contrary, we'll stop when there's nothing left to rip out ;p) Currently the size of it is quite manageable. This is not to say each of us know every corner of the code (at least I don't), but having an overall understanding is enough to get to a particular detail when needed. In the future (0.12, 1.0?) I think it's even conceivable that the major subsystems (versioncontrol/ticket/wiki) become distributed as plugins. We could still provide ways for having an easy "standard" Trac install. > Those are of course just suggestions. > > But it would be nice to have at least a very basic document with and > overview of subsystems (components) and the developers working on them. Well, as I said above, better use the queries for that. -- Christian --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
