[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Blockers in processes (Was: etiquette of bothering other developers?)

A levelezőm azt hiszi, hogy Stephen Birch a következőeket írta:
> Unless there is something that prevents it, you could always fix the 
> problem yourself and send them a patch.
> That often works and is usually very welcome.

The problem was not with a package. It was the usual case:
there is a activity in a process of the debian project
which can be solely done by an overwhelmed developer.

It has been solved since, but took approx 5 months. Given that
it is a 5 minute work, I view it as a bit too long time.
(two and a half month to figure out the way to go,
another two and a half waiting for the developer).

I do not give further details on the issue on purpose,
because I do not want to blame it on the developer in
question; I believe it is a problem with engineering our
processes rather than with the developer in question.

Lesson to be learned:
-Minimize the critical activities in our processes.
  Critical activity is which needs privileges a
  mortal developer does not have. There should be
  such activities, but their number should be
  as low as possible. It would be helpful to have
  at least two people as responsible for these
  activities, but one having an expressed authority,
  like with packages: there might be more co-maintainers,
  effectively with the same rights, but there is
  only one maintainer.
-Make these activities visible and measurable, and help
  for the responsible to not forget their todo. It can
  easily done by tracking them in the BTS (or whatever).

The zeroth step is to figure out what critical activities
do ve have now. I guess that experienced developers can
list them by heart. Please do so, as I am interested,
and the list will be helpful.

GNU GPL: csak tiszta forrásból

Reply to: