overview
==========
about teams
-------------
I hope that one day every package shall belong to one or more team.
So I propose that first every package which is taged orphaned,rfa, rfh
shall belong to at least one team (different from QA)
about complexity
--------------------
I think it could be interesting if each package could contain
information about its complexity.
It would be easier for people wanting to maintain an easy package to
find one.
So hopefully, it would attract new maintainers.
The project could have a snapshot of its global complexity.
my response
==============
my previous proposition
---------------------------
http://lists.debian.org/debian-devel/2012/03/msg00768.html
followed by
--------------
http://lists.debian.org/debian-devel/2012/03/msg00794.html
--
>>> If I need help on my package, why should it belong to a team when I
file a RFH?
If every packages which are taged orphaned,rfa or rfh, belonged to a team,
each team could have a page with the list of all the packages needing
some attention.
So that the people who have the more chance to be interested in the package
would be better informed.
Someone interested to join a team could go to this page and find easily
some easy packages to maintain.
--
>>>That's something that is incredibly subjective,
I suggest that information about the difficulty of the package would be
automatically
generated when you build the package. So that it won't be subjective.
Information about the langage(s) should also be included.
--
>>> bound to change as things arise
The complexity information would be relevant for one build and would be
updated at each upload.
So, if after some time, the package requires custom rules, the
complexity information would change.
We would also have an history of the complexity of the package.
The description of the difficulty of the package could/should be in the
policy
and could change, if needed.
--
>>> and of limited utility
I have made a proposition about how the information could be displayed.
If everybody think it has no utility, it won't be implemented.
--
Henri LE FOLL