In message <[EMAIL PROTECTED]>, "Adam R. B. Jack" writes: >judging health, we had one gentleman go to the trouble of digging out the >algorythm for FOG from Gumpy CVS, evaluating it, and submitting a JIRA entry >(which I agree with, BTW). That is effort, that is motivation. The loss of >"team pride" (maybe) of having their FOG factor halved was a motivator.
I had actually written a couple aborted emails (parts of which I cut and pasted into the improvement issue report) about the topic over preceding months that I never sent to the list because they sounded like I was making mountains out of mole hills and adding unnecessary noise when Gump committers were hard at work making more important improvements. I'm sure I sent a poorly articulated email about it around the time FOG was first added to the generated results. At any rate, it's been on my mind for a while since I believe it's inevitable lots of folks are going to pay attention to Gump because it's so handy. The FOG factor halving just reminded me of the topic and gave me a concrete example of why it can be misleading. >think we (as a group) keep overlooking one main thing. Gump is a social >experiment but we keep using the techie's golden hammer -- more >technology -- to try to solve it. ... >In summary -- my point is we've not explored the social solutions to the >Gumpmeister headache, and I'd love to hear other ideas on how we could >leverage that. I agree with what you said. If everyone is paying attention to Gump, then it matters little if you can't pin down exactly who's responsible for a failure because everyone who gets a nag works toward identifying the nature of the problem and coordinates with other projects to resolve the problem. Ultimately, Gump fosters cross-project cooperation. >Perhaps we ought copy 'affected' projects on nags, so the recipient & >those affected know who is affecting them. Nags are (right now) too >personal/private & a team can quietly sit on them. I think that would be very useful, but it could be limited in some way so that code bases used by hundreds of projects (e.g., parts of commons) don't generate hundreds of nags. Perhaps affected projects would receive an abbreviated email and another one after the problem is resolved. Also, you don't want a cascade of emails going out because of failures in multiple code bases and affected projects. So maybe a summary nag could go out to each project, tailored to that project. The summary would list all failures in code bases that depend on the project and all failures in code bases depended on by the project. Actually for the "depended on" code bases, it's probably better to list all dependencies and success or failure status of each because a code base can cause a failure in a project and still have built successfully. These customized failure summaries would avoid the need to automatically determine the exact source of a failure and whom to nag because it presents humans with a list of possible places to start hunting. Only if everybody ignores the emails does it fail to provide any benefit. If a small group of projects take an active interest, their connections to other projects should propagate responsiveness in general over time. daniel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
