The roads I take...

I have blogged recently about my contract to help in the area of crash reporting. Specifically, I am trying to help the Socorro team (which works on the crash-stats system) by gathering and presenting the engineering needs and use cases for reports and features that help us analyze trends and find and diagnose problems quickly. I'm not on the Socorro team myself but on the CrashKill team, which makes sure that the most important stability problems in Firefox actually get addressed. I will work closely with the Socorro team to ensure that they have what they need to implement some of these features and understand their priorities so they can find the right place on their roadmap. Understanding what crash-stats users need helps ensure we ship as stable as possible Firefox releases.

In this context, if you are using the crash-stats system, I would like your input; What are some of the use cases you run into most often? I'd be interested in hearing from developers, QA, release manager, etc. What questions are you trying to answer from crash-stats?

I will be going through many of the items currently in bugzilla and helping to prioritize them as well as put together detailed specs. Helping determine the criteria for detecting explosive crashes is one issue I am currently working on. If you think of additional reports that would be useful, please make sure there are bugs filed (under Webtools/Socorro) and CC me so I can understand the requests and help to get them in the development pipeline.

Thank you!

Vor einigen Monaten habe ich schon (auf Englisch) darüber gebloggt, dass sich meine persönlichen Prioritäten verschieben - und je mehr ich über die Zukunft meiner selbst und des SeaMonkey-Projekts nachdenke, wird mir klar, dass ich dort sein möchte, wo Innovation passiert und die Zukunft des offenen Webs gestaltet und nicht nur konsumiert wird - und je mehr ich die Dinge aus einem möglichen Firefox-Blickwinkel ansehe, desto mehr habe ich das Gefühl, dort hin zu gehören. Es fühlt sich für mich besser an, über Vorschläge, die in verschiedenen Foren anfallen, im Sinne von "was heißt das für Mozilla als ganzes" nachzudenken als von "was heißt das für SeaMonkey". Ich fühle bei dieser Sicht mich wohler, und ebenso, wenn es darum geht, Firefox und das offene Web weiter zu bringen - auch wenn ich derzeit noch tief im SeaMonkey-Projekt stecke.

Aus diesen Gründen habe ich auch bereits begonnen, einige meiner Verantwortungsbereiche im SeaMonkey-Projekt an andere zu übergeben - wie das Release-Engineering an Callek, zum Beispiel - und ich arbeite an weiteren derartigen Schritten. Im Endeffekt möchte ich, dass mir nur mehr die deutsche Übersetzung und der "Owner"-Status im comm-central Build-System übrig bleibt, sowie einer der Mitglieder im SeaMonkey-Council zu sein - zumindest im Moment. Aber bis dorthin ist noch einiges zu tun, und ich möchste, dass dies ein sanfter, schrittweiser Übergang wird, sodass das SeaMonkey-Projekt aus dieser Zeit mindestens gleich stark, wenn nicht stärker als vorher, herausgehen kann.

Gleichzeitig - und das ist der Kern dieses Beitrags und etwas, das sich schon seit einiger Zeit zusammenbraut - beginne ich, woanders Erfahrungen zu sammeln. Ab dem heutigen Tag beginne ich einen Teil meiner Zeit offiziell für Mozilla zu arbeiten - derzeit heißt das, auf Auftragsbasis halbzeit ca. 3 Monate lang an einem Projekt zu arbeiten, aber ich hoffe, dass daraus ein fruchtbares Verhältnis wird, das in der Zukunft noch große Zeiten erleben wird.

Meine Arbeit bei Mozilla ist dabei generell im Bereich des "Program Management" angesiedelt - das konkrete Projekt, an dem ich in den nächsten Monate arbeiten werden, ist dabei, eine Strategie für Socorro (unser Absturz-Statistik-System) aufzustellen. Ich werde nicht an Code arbeiten, sondern mit dem Socorro-Team und den anderen Mozilla-Managern und -Entwicklern zusammenarbeiten, um einen Plan zu finden, woran die Entwickler in den nächsten Monaten arbeiten werden, um eine zusätzliche Perspektive zu finden, wie das Absturz-System verwendet werden kann, um als Hilfe für Release-Entscheidungen zu dienen, und sich nicht nur um die Analyse spezifischer Bugs dreht. Eine Menge Arbeit steht bevor, die über 400 Änderungswünsche und Bugs zu konsolidieren, die sich um das Socorro-System aufgestaut haben und um einige detailliertere Spezifikationen für etwas komplexe Gebiete aufzustellen, sodass wir Systeme bauen können, mit denen wir Absturzdaten besser verstehen und effektiver nutzen können. Ich kann jedenfalls aus der gesamten Community Vorschläge gut gebrauchen, wie wir dieses Ziel möglichst gut erreichen können.

Die positive Seite an einem Übergang in dieser Art für mich liegt darin, dass Socorro für alle Mozilla-Anwendungen zur Anwendung kommt und ich etwas Erfahrung (wenn auch nicht allzu viel) mit der Verwendung dieses Systems habe. Da ich ebenfalls Erfahrungen mit dem Release-Management von Mozilla-Produkten habe und den Diskussionen von Firefox-Release-Managern sowie der Security-Gruppe schon länger folge, sollten mir Einschätzungen leichter fallen, wo der Fokus für Absturz-Berichte und -Statistiken liegen kann.

Für mich persönlich habe ich dem Projekt den Spitznamen "Veridian 3" (eine fiktionelle Absturzstelle) aufgesetzt, und in einem ersten Klassifizierungslauf werden meine internen Tags auf Bugzilla daher mit "V3" beginnen - aber diese Name sollte nicht aus meiner privaten Verwendung anderswo hin durchschlagen, um andere nicht verrückt zu machen.

Einiges an konzentrierter Arbeit liegt vor mir und auch einige Dinge, die ich nicht gewohnt bin, wie einer spezifischen Person Bericht zu erstatten bzw. unterstellt zu sein oder Pläne zu erarbeitet, für deren Ausführung tatsächlich andere bezahlt werden, aber ich bin zuversichtlich, dies erfolgreich zu meistern und meinen Beitrag zu einem besseren Absturz-Statistik-System für uns alle zu leisten.

Also, seid darauf gefasst, dass ihr mich in naher Zukunft etwas weniger auf den üblichen Plätzen seht, aber dafür an einigen neuen Bereichen!