Re: [Ekiga-devel-list] HELP !!! (Was Re: [VALVE] Ubuntu Edgy)

[thomas schorpp <t schorpp gmx de>]

hi PPL, hi Jan, hi staff,

Damien Sandras wrote:
> Hi,
>
> Le mercredi 07 f�ier 2007 �6:35 +0100, Jan Schampera a �it :
>
> > Folks,
> >
> > http://bugzilla.gnome.org/show_bug.cgi?id=400590
> > http://bugzilla.gnome.org/show_bug.cgi?id=401351
> > http://bugzilla.gnome.org/show_bug.cgi?id=404157
> > http://bugzilla.gnome.org/show_bug.cgi?id=404612
> > http://bugzilla.gnome.org/show_bug.cgi?id=405193
> >
> > (and masses of similar stuff I didn't find yet, plus masses of similar
> > stuff from other programs than Ekiga)

Just blaming Ubuntu Maintainers (QA/Configuration Managers) 
for bugs does not help here and brings in frustration,  Jan, take it as feedback for 
incomplete CM advise from the Ekiga Project-Management (Sorry, 
Damien, but I will reason below) and incomplete outsourcing QA-Cycle, 
and communication failure. In Free Software Projects Practice in Linux, QA is 
outsourced to distro maintainers, but QM can never be, the PPL is in charge.

I've reported such process weaknesses before on this list and IRC, but it 
got simply ignored.

> We would really need a few persons interested in Ekiga, and who could
> take in charge the role of triaging bugs.

Just hiring a testing department is depreciated SW process practice and will not cure 
the showing up management weaknesses. 
Keep that outsourced to the distro maintainers and their 
users. Taking it from them by force would be a violation of current OSS practice 
we must respect and would lead to more and unsolvable communication problems and 
possibly complete breakdown of the QA-Cycle and thus, a chaos project.
According to modern SW lifecycle process audits results in ISO 15504 and SEI-CMMI, 
and the SPR Institute's publications, books from german senior PMM practioneers,
the failures here do not mainly come from development and CM or users(testers),   

> We sometimes receive interesting bug reports, often not. 

Invite the outsourced QA (distro maintainers) to *documented* weekly online meetings 
and provide a guideline  for such a classification and CM advise from the ekiga devs 
and self-assessment, maintainers have insufficent input otherwise, 
maybe You, Damien, want to publish Your complete Project Management 
ways and habits and reasoned decisions for external audit, so the distro 
maintainers get enough information for CM and QA, they should be 
professional enough, again, no reason to blame ubuntu maintainers, here, 
ekiga teams fault alone. not doing so just copies proprietary companies management 
practices. 
they could do much more forward error correction then, and reason their 
own QA/CM project management processes better and give reasoned feedback 
upstream, what is what You like to have, isnt it?

> I am loosing much time triaging them.
> I am loosing much time trying to reproduce them.
> I am loosing much time trying to get information from users to reproduce
> the problem.

Devs know their library dependencies and other CM well and should provide them *tightly* 
to the distro maintainers, this has not been done restrictive and full enough in the past.

Focus on process too, not only on the product.

Again, most Bugs are *traditionally* coming from management failures, pls do a self-assesment 
of Your practice and decisions and what could follow them. 
Just think the chain back to the top and dont forget the risk-management 
before having the dev team moving forward to fast, first fix the bugs, then 
move forward to new designs, other would be proprietary business practice 
always releasing buggy software and then selling hotfixes, 
therere much books out about this for SW PMM.
Papers and easy guidelines are also availlable from esi.es and sei.cmu.edu, 
spr.com maybe, 
until now I found only proprietary self-assessment/QM software tools 
(my fault, Ive had enough time to implement some, but as You know I'm 
a very slow coder, and there was real *no* interest from OSS managers, 
i've failed for acceptance to introduce such practices on qa.debian.org years before, 
free projects cant be controlled the classic industry QM way and I am no senior QM 
or process consultant myself and missing a PHD title for the needed acceptance).

You do not need to read all of it, therere quick guidelines books for PMM 
practioneers available from Your local university library.

First address the communication issues to get control back and publish Your 
management details if You want assessment help, I could translate and format Your 
output according to ISO 15504 and other standards and best practice and 
map to PMM-Practice checklists. Get some good books of practice from 
senior SW-PMM practioneers for communication basics in this science, 
if Youre not mature enough in this.

> Most of the time, people send me privately -d 4 outputs. I am forced to
> ignore them.

give reporting guidelines in the README of packages.

provide another contact address with autoreply service delegating to the correct reporting places, 
proprietary hotline and customer-care practice can be used for this as immediate solution until 
users and CM/QA maintainers know the right way. Just publishing will not help for a > 80000 
users project.

> Very often, people send me private e-mails to cancel their Ekiga
> account, or to ask a question. I am also forced to ignore them.

s.a.

> I would really need help.

pls concretize more what You think would be help.

> Not from you Kilian, Jan, Julien, Yannick. You are already doing a lot
> for Ekiga. We need fresh air, from new people.

Why exclude Kilian? He's a senior and CM for many packages and distros and leading member 
of distro QA teams and provides valuable You ignore sometimes for reasons that indicate 
P-CMM issues (not only from the rumors).

Proprietary Biz firing staff and hiring new habit. Will lead to high risk for Your goals and has never succeded, 
in practice, milestone reaching times and costs have mostly doubled doing so. 
New people dont know history and habits of this project and need 6 months to work in.
This is no solution in short of a release.

> Any taker ?

If Kilian is out, I'm out, too. But if You publish Your practices I would try to do a complete 
ISO15504 or more modern standards and practice assessment within 6 months.

comments and corrections especially from senior practioneers, pls, this is first cigarette early morning output ;)
it is no shame to ask for help for such a big project, Big thank You, Damien. That was tough.

y
tom