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

hi PPL, hi Jan, hi staff,

Damien Sandras wrote:

Le mercredi 07 f�ier 2007 �6:35 +0100, Jan Schampera a �it :


(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 and, 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 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.


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.


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