PROJECT - Component Leads
Ilias Lazaridis
"component/subsystem" "leads/owners".
I have difficulties to identify the relevant component-owner within the
trac project.
Possibly the project should provide a document which mentions the
responsibilities of the trac team members.
Component Owners:
* get the tickets subjecting the component assigned
* delegate tasks to contributors or to themselves
* communicate requirements and requerst to other component owners
* assing subcomponent ownership (e.g. file level) for external
contributors
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).
And: this ensures a consisten coding style (e.g. functional form
ComponentOwner A, OO from ComponentOwnerB).
-
I think Component Ownership is the best way to manage a project which
becomes larger and larger.
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.
.
Christian Boos
> 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
Ilias Lazaridis
> 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, :
> > 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.
.
Christopher Lenz
> 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.
Even if we had something like "component leads", what would anyone
need this information for? All communication should happen over open
channels such as the ticket system, the mailing lists, IRC, etc.
I'm strongly against any kind of formal component/code ownership in
open-source projects, where someone would have to ask someone else
whether he can check in code for some component. That's a model that
can not work for relatively small open-source projects that rely on
spare-time contributions by volunteers.
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
Ilias Lazaridis
> Am 12.11.2006 um 11:50 schrieb Ilias Lazaridis:
> > 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.
>
> Even if we had something like "component leads", what would anyone
> need this information for?
Focusation
> All communication should happen over open
> channels such as the ticket system, the mailing lists, IRC, etc.
Of course ( Personally I prefere the ticket system / mailing-lists =
asynchronous written conversation)
> I'm strongly against any kind of formal component/code ownership in
> open-source projects, where someone would have to ask someone else
> whether he can check in code for some component. That's a model that
> can not work for relatively small open-source projects that rely on
> spare-time contributions by volunteers.
I've stated some reasons in this thread.
And again:
The trac-team underestimates the complexity of the trac-development.
See this thread for further details:
PROJECT - Decoupling Core (Framework) from Trac (Application)
http://groups.google.com/group/trac-dev/browse_frm/thread/094c62b02b2c4b33/#
,