Re: Emphasize teams, not packages
Frans Jessop wrote:
> First, as the announcement just came a few days ago some are ignoring
> bugs for months. If a team was on the project that is less likely to
Hmm this already happens today with packages who *are* maintained by teams.
> Second, collaboration on ideas for individual packages, by those who are
> directly involved with the package, can occur making the future of the
> package better.
Hmm might be true for really big packages.
> Third, Instead of always having the hard process of trying to get someone
> to adopt will go away for team members can take over.
> Fourth, MIA's will not be as big a problem.
The problem is, that not every tiny little package requires a team to
maintain it. And the big packages. like kernel, xorg, kde, ... already are
maintained by teams.
> Fifth, more heads on a package are better than one
> Sixth, those applying to be a DD will have worked along side a Developer
> who will better see �how this one contributes and fixes bugs.�
But others can't be sure, that *all* New Maintainers meet the same
requirements and standards. Some NM might be lucky to find a DD who is
rather sloppy and might become a DD without much effort while others have
to work much harder (and learn much more) to become a DD.
> Seventh, It will increase teamwork. :)
> Now for my hypothetical situation:
> Future A:
Don't forget, that becoming a DD today takes at least a year -- and the
average DD contributes ~7years before leaving the project -- I don't think
that we will see 10.000 DDs in the near future. But what's more important:
I don't see a problem with *too much* packages, since unused packages
sooner or later disappear from the archive.
> Future B.
Again, I think teams are not allways necessary, espeacially when we speak
about small packages. On the other side the big ones are usually already
maintained by teams.
But I agree that more teams in general would be a good idea since it happens
quite often that a bug gets not fixed because the only maintainer is on