11

Click here to load reader

A Day in the Life of a Bug --- sinnvoll zu Open Source Projekten beitragen

Embed Size (px)

DESCRIPTION

Kurzvortrag zu Möglichkeiten, in Open Source Projekten aktiv zu werden, mit Fokus auf Bugs (melden & beheben). Gehalten am 23. 5. im Rahmen der Projektwoche am Institut für Informatik (Thema "Der erste Schritt zu Open Source") der Universität Rostock.

Citation preview

Page 1: A Day in the Life of a Bug --- sinnvoll zu Open Source Projekten beitragen

A day in the life of a bugSinnvoll zu Open Source Projektenbeitragen

Vortragsreihe Der erste Schritt zu Open Source

Roland Ewald

23. 5. 2013 c© 2013 UNIVERSITÄT ROSTOCK | LEHRSTUHL FÜR MODELLIERUNG & SIMULATION (PROF. UHRMACHER) 1

Page 2: A Day in the Life of a Bug --- sinnvoll zu Open Source Projekten beitragen

Viele Wege führen nach Rom

1. Software nutzen2. Dokumentation verbessern

(Blogs, Foren, Chats, Stackoverflow, usw.)3. Lokalisierung (Übsersetzung)4. Milestones und RCs testen5. Bugs reporten und fixen6. Neue Features programmieren von: OnFoot4now (Didi) / flickr.com

23. 5. 2013 c© 2013 UNIVERSITÄT ROSTOCK | LEHRSTUHL FÜR MODELLIERUNG & SIMULATION (PROF. UHRMACHER) 2

Page 3: A Day in the Life of a Bug --- sinnvoll zu Open Source Projekten beitragen

Warum so wichtig?

Feedback für:

• Entwickler

• Andere Nutzer(Bsp: Jenkins)

von: xkcd

23. 5. 2013 c© 2013 UNIVERSITÄT ROSTOCK | LEHRSTUHL FÜR MODELLIERUNG & SIMULATION (PROF. UHRMACHER) 3

Page 4: A Day in the Life of a Bug --- sinnvoll zu Open Source Projekten beitragen

Leichter gesagt als getan

Falsche Arten von Bug Report:

• Smug Report: natürlich weißt Du schon genau woran es liegt

• Drug Report: was hast Du denn genommen?

• Shrug Report: OK, irgendwas hat irgendwie nicht funktioniert?

(von: stackoverflow (Nutzer Aaronaught), verfügbar via stackprinter.com)

Aber: Jeder Report ist besser als gar keiner...

Aber: „SELECT“ ISN’T BROKEN (http://pragmatictips.com/26)

23. 5. 2013 c© 2013 UNIVERSITÄT ROSTOCK | LEHRSTUHL FÜR MODELLIERUNG & SIMULATION (PROF. UHRMACHER) 4

Page 5: A Day in the Life of a Bug --- sinnvoll zu Open Source Projekten beitragen

Leichter gesagt als getan

Falsche Arten von Bug Report:

• Smug Report: natürlich weißt Du schon genau woran es liegt

• Drug Report: was hast Du denn genommen?

• Shrug Report: OK, irgendwas hat irgendwie nicht funktioniert?

(von: stackoverflow (Nutzer Aaronaught), verfügbar via stackprinter.com)

Aber: Jeder Report ist besser als gar keiner...

Aber: „SELECT“ ISN’T BROKEN (http://pragmatictips.com/26)

23. 5. 2013 c© 2013 UNIVERSITÄT ROSTOCK | LEHRSTUHL FÜR MODELLIERUNG & SIMULATION (PROF. UHRMACHER) 4

Page 6: A Day in the Life of a Bug --- sinnvoll zu Open Source Projekten beitragen

Leichter gesagt als getan

Falsche Arten von Bug Report:

• Smug Report: natürlich weißt Du schon genau woran es liegt

• Drug Report: was hast Du denn genommen?

• Shrug Report: OK, irgendwas hat irgendwie nicht funktioniert?

(von: stackoverflow (Nutzer Aaronaught), verfügbar via stackprinter.com)

Aber: Jeder Report ist besser als gar keiner...

Aber: „SELECT“ ISN’T BROKEN (http://pragmatictips.com/26)

23. 5. 2013 c© 2013 UNIVERSITÄT ROSTOCK | LEHRSTUHL FÜR MODELLIERUNG & SIMULATION (PROF. UHRMACHER) 4

Page 7: A Day in the Life of a Bug --- sinnvoll zu Open Source Projekten beitragen

Was sollte ein Bug-Report enthalten?

(Generell: Checkliste des jeweiligen Projekts beachten!)

• Genaue Version der Software

• Komplette Fehlermeldung (Log)

• Kurze Beschreibung der Ausführungsumgebung

• Kurze Anleitung zur Reproduktion (evtl. Testcode)

• Eventuell ein Patch (ggf. später)

23. 5. 2013 c© 2013 UNIVERSITÄT ROSTOCK | LEHRSTUHL FÜR MODELLIERUNG & SIMULATION (PROF. UHRMACHER) 5

Page 8: A Day in the Life of a Bug --- sinnvoll zu Open Source Projekten beitragen

Klingt kompliziert?

Ist ganz einfach mit verteilten Versionskontrollsystemen...und ’Social Coding’ Plattformen wie github oder bitbucket!

1. Bug in den Issue Tracker eingeben

2. Kopie erstellen: fork (kann privat sein)

3. Problem beheben: changeset(s) erzeugen (=patch)

4. Patch ans ’Original’-Projekt zurückschicken: pull request

5. Besitzer: Code Review (evtl. mehrere Iterationen)

6. Besitzer: merge (oder auch nicht ;-)

(Mehr Doku: https://confluence.atlassian.com/display/BITBUCKET/Working+with+pull+requests)

23. 5. 2013 c© 2013 UNIVERSITÄT ROSTOCK | LEHRSTUHL FÜR MODELLIERUNG & SIMULATION (PROF. UHRMACHER) 6

Page 9: A Day in the Life of a Bug --- sinnvoll zu Open Source Projekten beitragen

Demo — http://bitbucket.org

23. 5. 2013 c© 2013 UNIVERSITÄT ROSTOCK | LEHRSTUHL FÜR MODELLIERUNG & SIMULATION (PROF. UHRMACHER) 7

Page 10: A Day in the Life of a Bug --- sinnvoll zu Open Source Projekten beitragen

Weitermachen!

von: cardkarma / flickr

• http://jamesii.org :-)bzw. [email protected]

• http://producingoss.com

• http://openhatch.org

• http://whatcanidoformozilla.org

• http://github.com/explore

• http://sourceforge.net

• http://code.google.com

• http://bitbucket.org

• http://goo.gl/lCB0E

(itworld.com, 7 open source projects to cut your teeth on)

23. 5. 2013 c© 2013 UNIVERSITÄT ROSTOCK | LEHRSTUHL FÜR MODELLIERUNG & SIMULATION (PROF. UHRMACHER) 8

Page 11: A Day in the Life of a Bug --- sinnvoll zu Open Source Projekten beitragen

Danke für die Aufmerksamkeit.Fragen?

Dieses Werk ist unter einer Creative Commons Lizenz vom Typ Namensnennung 3.0 Deutschland zugänglich. Um eine Kopie dieser Lizenz

einzusehen, konsultieren Sie http://creativecommons.org/licenses/by/3.0/de/ oder wenden Sie sich brieflich an

Creative Commons, 444 Castro Street, Suite 900, Mountain View, California, 94041, USA.

23. 5. 2013 c© 2013 UNIVERSITÄT ROSTOCK | LEHRSTUHL FÜR MODELLIERUNG & SIMULATION (PROF. UHRMACHER) 9