On 7/9/06, seth vidal <skvidal@xxxxxxxxxxxxxx> wrote:
On Sun, 2006-07-09 at 20:46 -0600, Stephen John Smoogen wrote: > I can tell from longer history, that this has come up in 'lessons > learned' since at least 1998.. and keeps coming up. It has always been > "next time we will communicate better" but something always comes up > and there is always a good list of reasons why communication broke > down again (lack of people, extra demands on engineers, etc.). At this > point, I would have to say the problem needs serious management power > aimed at it with it being put as a priority. A developer can only deal > with so many issues (features, bugs, packages, upstream communication, > downstream communication) and the company has to manage that number or > it will end up with burnt out developers, poor community relations, > and tanking sales. > I have a problem with this statement. This issue was brought to the board on friday. We've had all of 2 days to discuss and I'd like for there to be a board meeting before we make a final statement.
Sorry, I am trying to show a systematic problem with communication that needs to be looked at by the board. It is a problem that has been brought up internally multiple times at RH when I was there.. and your answer is pretty much the stock one: "We just got this problem, and have had 2 days to fix it... " I am talking about a general problem with communication. The bug was opened in November of 2005. There was no communication until it was closed from Red Hat other than marking a bug duplicate. I have a couple of bugs in the same condition from RHL 8.0. [The problem may be that there isnt a significant organization memory to
It's hard to communicate an answer to a problem when we didn't really know there was one. Its one package out of what? 3000? And it's one bug out of 150K?
I do not know how many bugs it is currently. When I did a close-a-thon of bugs during the end of RHL, the number was in the hundreds of open bugs in the NEW condition that had no developer interaction. Currently while there are over 5000 NEW bugs in bugzilla I would say about 2000 of them look over 6 months old.
How do you think this should have been handled?
Well, my point of view is from a service background so my view towards customer interaction/satisfaction is where I come from. Bug reports are as much a public face of Fedora/RH as the website. A customer should get some sort of interaction from an official person within 7 working days. This can just be a triage of: Thanks for the report, it looks to be a duplicate of XYZ so I am combining it in this report. Will have to work with the upstream maintainer on getting this fixed. It may take a while to get a proper fix though so this bug may go into hiatus for a while. This looks to be a feature request that would have to be in a future release. Will put on as a 'blocker' for project management to look at. Thanks for the report, currently engineering is having to concentrate on work in <fill in sections here>, and are needing to keep RPM in a conservative mode. We are backporting changes from upstream RPM that does not overly change the behavior of RPM-4.2. We are looking to focus on a major change to RPM in a future release.
A problem has been happening in a bug in bugzilla The maintainer didn't know what the best answer was so he brought it to the board We've been discussing it and will come up with something shortly. why is this not communicating? How did we fail to communicate?
Ok the issue for me is trying to say that communication delays/failure have been a long term problem. Each time a new organization management comes in and says they will deal with it but seem to focus on the particular crisis versus the entire problem. Then a new group comes in and we repeat, lather, rinse. I should have phrased my earlier email differently, but what I am trying to do is act as a memory unit: Bugs take a long time to get interaction, people get pissed, community problems surface, and 'management' reacts. In this case, management realizes this has occured in the past, and can 'act' in a way to study and cure the larger problem versus one aimed at specifically at RPM. Does that clear up what I am trying to say? -- Stephen J Smoogen. CSIRT/Linux System Administrator _______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board _______________________________________________ fedora-advisory-board-readonly mailing list fedora-advisory-board-readonly@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board-readonly
