On Sep 4, 2005, at 2:22 PM, Lina Pezzella wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sep 4, 2005, at 6:57 AM, Grobian wrote:
Don't assume that not seeing work from a developer means they're
not working. For instance, as a result of recent emails on this
list, Hasan and I have moved a large chunk of our time that was
previously spent on porting/keywording e-mails to drafting
documentation.
Have you joined the docs team yet?
Additionally, a lot of developers choose to work on long-term
projects in an overlay and thus don't necessarily commit things to
the portage tree proper on a regular basis.
Who is working on what where when?
This being said, there are a good number of inactive developers. In
a previous e-mail on this thread, Hasan and I explained our
inability to take care of this problem without assuming the "Lead"
position. Since there were no direct objections to our taking this
position
I think I have to object.
The current direction is not ever going to be good for anyone, users
or developers, and if it continues in the current direction it runs a
high risk of being booted from Gentoo proper IMHO. I don't think any
amount of policy, PR, elections, hand-waving, documentation, whatever
is going to solve the problem. The best ideas I've seen proposed on
this list have gotten little, if any, response from either of you. It
seems apparent you think writing a bunch of policy and shuffling some
names around on a webpage is going accomplish something.
The macos project had docs, webpages, strategical operational
structural senior team lead documentation managers and co-presidents,
and /. announcements before the alpha version was even finished.
There has been little progress made since a year ago, other than more
ebuilds that install to / that no users want anyway (can you blame
them?)...
The g/fbsd team is waaaaaaay farther along than we are, and they
still have 0 official docs/policies/etc. I don't believe that to be a
coincidence.
, we will make the appropriate changes to the project page[1] and
begin conversation with devrel regarding our inactive developers.
Let the council deal with inactive developers, IIRC there are
provisions for exactly this problem.
Hopefully this is still okay with everyone. More to follow
regarding this in a new thread once we have more information.
Currently, we only discuss the way 'up', but maybe the way 'down'
should be in the picture too. An AT should be considered to be
'active'. Where active means that such AT can do some useful work
on a regular base. (Note: this implicitly requires devs to be at
least as active as the AT.) If not, while there is work enough,
such AT should be removed. Might sound obvious, but if there are
no hard rules for it, noone will get removed.
Agreed. So far, then, we need documentation/policy on the following:
1) Inactivity (Developers and ATs)
This should be dealt with by the new council and/or devrel, but, how
is anyones inactivity a problem (other than the obvious lack of
manpower) ? Yes its annoying, but out of all the problems that need
to be solved and work to be done, this seems like an odd thing to
focus on.
2) Probation for ATs (Probation for Devs is covered by devrel)
I think there shouldn't be a separate set of rules for macos ATs, you
should work with the other arch teams and establish something project
wide. We are already in the corner, no reason to make macos even more
of a corner case.
3) Selection of New Developers / New ATs
What needs to be documented that isn't already handled by devrel?
4) What each developer is working on (10,000ft overview)
http://cia.navi.cx/stats/author/<nick> and bugs.g.o are fairly
telling...
5) Specific/Misc Policy such as where to install python modules,
package.mask usage, Unstable/Stable Keywording, etc
These things should be established before they are documented. Design
by declaration is not a good idea.
All of this will be in the form of a Gentoo for Mac OS X policy
handbook, which will take time (specifically (5) above).
Suggestions for what should go in here would be highly valued.
I think the wiki is better suited for us at this point, as everything
is in a fairly heavy state of flux. This also allows users to
participate.
Yes, nice idea, but I think we should look at the problem from
inside this very team first. I would consider the average
participation level very unhealthy.
Again, please don't confuse lack of commits with lack of
participation. Also note that we have only a handful of active
developers. Once we agree upon policy for inactivity, we can make
some progress with weeding out those that are not contributing.
I haven't been too active in commits lately myself...RL,work and
trouble with the 'big picture' of the project has slowed me down...
This team is also very opaque, it's almost impossible to know what
someone is working on.
Like we said, we'll address this shortly. We felt that AT's are
more important than this right now. To give an idea:
Kito is working on Darwin stuff. I'm sure he can elaborate if he
cares to.
I guess I don't work on macos stuff? I feel like I've been fairly
vocal as to what I am / will be working on. Yes Darwin, but more-so
macos as you can't have one without the other. For the past week,
I've been getting familiar with the portage rewrite as much as
possible.I'm also in the ppc and sound herds and maintain several
sound packages, also working on a Darwin port for the pegasos and a
LiveDVD designed for audio production. I try to keep my devaway
current, there are times when I get too busy with work and life that
will keep me away from gentoo for days at a time. I'm not really sure
how I can be any more transparent...no, I won't blog :p
Before discussing these other issues, however, can we all agree
upon what is necessary to bring ATs on board? Is the documentation
we have sufficient for that purpose, or is there more that needs to
be added? (Note: policy on converting ATs to Devs is not needed yet.)
I think ATs are a great idea, but work better with a larger dev/user
base. We couldn't even keep up with the bugs/patches/requests/reports
submitted by our existing small base of users. The notion of 'not
checking the ATs work' seems very odd, if an active dev is merely a
proxy for a users work, that user should just be mentored and become
an official dev.
--Kito
--
[email protected] mailing list
