FIRST is really looking into the Einstein problems

[Jim Wilks]

Originally Posted by Bruceb

This from FIRST

We have asked all weekend participants not to disclose details concerning weekend testing until our additional testing, results and initial conclusions are available to the entire community. The FIRST Engineering staff, with support of the external experts and the FIRST community experts are working with all deliberate speed on their analysis and recommendations. We understand everyone's desire to hear initial results and appreciate your continued patience.

I always see the "not to disclose details" card played when things didn't go well. I guess there was no aha! moment when the problem showed itself again. If there was truly good news, it would be shared immediately.

Just my $.02 worth.

[IKE]

Originally Posted by Jim Wilks

I always see the "not to disclose details" card played when things didn't go well. I guess there was no aha! moment when the problem showed itself again. If there was truly good news, it would be shared immediately.

Just my $.02 worth.

Or if you have a few likely contributors that you are trying to sort out. Or if you have a problem that you can have a solution to shortly. Or if you have a problem with no current solution and feel you need a proposed solution before you scare teams into not competing or...

There are a whole lot of reasons to not prematurely release ideas/data/anedotes. This reminds me of a neat story I read in WIRED a few years back.

[Mike o.]

Originally Posted by Jim Wilks

I always see the "not to disclose details" card played when things didn't go well. I guess there was no aha! moment when the problem showed itself again. If there was truly good news, it would be shared immediately.

Just my $.02 worth.

I wouldn't jump to the conclusion that there was no good news out of this past weekend. It is not an uncommon step in any engineering project/analysis to not disclose information until the analysis phase has been fully conducted. Sharing information, and especially having it go through the many phases of word of mouth can just add more confusion while they are in the concluding steps of confuting the testing and analysis. As someone who is very curious and anxious to see what has come of this investigation, I truly believe that we do need to be patient and let them fully get their work done so that we can get an accurate and concise conclusion and findings from all of this.

[Steven Donow]

Originally Posted by Jim Wilks

I always see the "not to disclose details" card played when things didn't go well. I guess there was no aha! moment when the problem showed itself again. If there was truly good news, it would be shared immediately.

Just my $.02 worth.

Yeah, as people already said, I don't think that's an accurate conclusion to jump to. It could easily be, "We think we may have found the issue, but we're not certain that's the issue, so we don't want people to say it's the issue, then have everyone get their pitchforks out when that's not the issue" or something along those lines.

[Jon Stratis]

When we have an issue in production, my manager doesn't just want to know what happened. He wants reliable, reproducible testing AND a fix proving we identified the correct answer before he'll disseminate information to other parts of the organization. Saying you found the issue and coming back a week later and saying "just kidding" is about the worst thing an operations team can do.

[Peter Matteson]

Originally Posted by Jon Stratis

When we have an issue in production, my manager doesn't just want to know what happened. He wants reliable, reproducible testing AND a fix proving we identified the correct answer before he'll disseminate information to other parts of the organization. Saying you found the issue and coming back a week later and saying "just kidding" is about the worst thing an operations team can do.

We are the same way where I work. We review with a team of engineering fellows along the way to make sure we haven't gotten off track at each step during the DIVE process. (Define, Investigate, Verify, Ensure)

If you during your investigation that you don't verify the cause of the problem you can't ensure it won't reoccurr. I would want to make sure my data supported the conclusions before they were published, and preferably have a working solution.

[qzrrbz]

Originally Posted by Peter Matteson

We are the same way where I work. We review with a team of engineering fellows along the way to make sure we haven't gotten off track at each step during the DIVE process. (Define, Investigate, Verify, Ensure)

If you during your investigation that you don't verify the cause of the problem you can't ensure it won't reoccurr. I would want to make sure my data supported the conclusions before they were published, and preferably have a working solution.

If you look at this as an "academic problem", you will come to a similar conclusion. It is very much looked upon badly if you publish in "the popular press" before you do so in a refereed technical journal!

[EricVanWyk]

Earlier this week it took me a little bit too long to realize that the reason my pen wasn't writing correctly was that it was actually a screwdriver. I'm going to have to ask for a few nights of honest sleep before signing off on a report.

[Al Skierkiewicz]

Originally Posted by Jim Wilks

I always see the "not to disclose details" card played when things didn't go well. I guess there was no aha! moment when the problem showed itself again. If there was truly good news, it would be shared immediately.

Just my $.02 worth.

Jim,
This could not be further from the truth. I just managed to get my preliminary reports (qty. 14) filed yesterday afternoon. They were likely the easiest to compile but were needed by others to complete their work.