Christian Boos wrote: > 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.
I am doing just this, but in an 'resusable' way, thus other potential contributors have less effort. that's because I have a personal interested that this project get's more contributors. > > 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. Ok, this works fine (at least if the component is within the trac. e.g., the "query" is not thererin) > In addition, this kind of "ownership" tend to vary over time, so a > document like that would quickly become obsolete. Not if such document is the central reference point. Possibly you could just provide such a document, pointing to the relevant queries (I could add this to t.e.o, too): something like: " You can see the Component Owner status based on a query on the actual tickets: e.g. for the wiki Compoment, : <http://trac.edgewall.org/query?status=new&status=assigned&status=reopened&group=owner&component=wiki&milestone=0.11> " > > Component Owners: > > * get the tickets subjecting the component assigned > > > it's already like that ok although mostly I see tickets get assigned to 'jonas' on creation, e.g.: http://trac.edgewall.org/ticket/4098 > > * 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.) ok > > 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). Ownership does not mean "solo-work". Collaboration is of course still possible. I estimate that this is a major factor in the delays within the trac-development: Missing seperation of concerns. > > 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) Of course. But I refere to the personal style of a developer (within the tolerance range of the Coding Style Document) A developer with a high grade of OO will be annoyed by functional additions (which can ruine an OO design). Same thing for an functional oriented developer, who will get annoyed by OO abstractions. Personally, I have problems with the low grade of encapsulation within the trac code. If I had to do coding work, I would at the same time refactor the code to become more OO and self-documenting. I could not do this, if another devoloper 'jumps-in' to help out (with positive intentions) whilst breaking my development flow and (re)coding style. I think that many developers like to have 'their' component, which they implement the requirements in the way they prefere. As long as they keep the api requirements, the basic coding-style and the shedule, they should be able to do what they want (without many discussions which reduce development throughput). > > - > > > > 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. "Trac" is not only the "trac core". I have the feeling that the whole trac-team, including lead-developer and project-lead have a wrong estimation about the complexity of the trac refactoring and the development effort for a 1.0 release. Otherwise you would invest some time in simplifying the project entry for new participants (either commercial or non-commercial). And otherwise you would just say to an developer offering to contribute: * what do you need? * here are the requirements! * here is your temporary component ownership! * here is your mentoring developer! * go ahead! > 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. Ok, I will do so. . --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-dev@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
