Добри практики при управлението на проекти с отворен код

Transcript

1. Добри практики при управление на проекти с отворен код (или “Само с кодене магията не става”) OpenFest 3.11.2013
2. Овертюра
5. Божидар
6. Бацов
7. Master
8. Търновец от скромен произход (говори на Ъ и се гордее с товЪ)
10. Мечка (намръщена)
11. Мечка (с мечета)
12. Специалният (Щастливият)
13. Най-големите (Батман е по-голям)
15. Мистериозен герой (злодея на снимката се за казва Васко Най-добрия)
16. Бездарен китарист (изключително бездарен)
17. Политически отговорен
18. Оставка!!!
19. Иииииии…
20. Има някакви интереси в областта на софтуера
22. Борец за хегемония на Emacs http://emacsredux.com ! @emacs_knight
23. Списва някаква проекти
24. RuboCop • Статичен анализатор на Ruby код • github.com/bbatsov/rubocop
25. Prelude • Дистрибуция на Emacs оптимизирана за хакери • github.com/bbatsov/prelude
26. CIDER • Clojure IDE & REPL for Emacs • Интерактивна среда за програмиране на Clojure в Emacs, изградена върху nREPL (подобна на SLIME за Common Lisp) • github.com/clojure-emacs/cider
27. Живее в GitHub (за добро или лошо)
28. Може и за лошо да е :-)
29. Пълната му кодография ! ! ! ! github.com/bbatsov
30. @bbatsov
31. За кого е тази лекция?
32. За хората, които поддържат свободни проекти…
33. … и за хората, които искат да допринасят към тяхното развитие.
34. Решавайте истински проблеми
35. Решавайте нерешени проблеми
36. Стъпете на добра основа
37. Хостинг на проект
38. Програма максимум • Поддръжка на модерни VCS • Интегриран issue tracking • User friendly • Интегрирано wiki • Download area • Безплатно
40. Лиценз
41. Важно да е има някакъв (и да е свободен)
42. GPL 2/3 не е вариант, ако пишете библиотека
43. Код
44. Тестове
45. Ако аз трябва да ви казвам защо са ви необходими не сте за тук!
46. Документация
47. Програмистите мразят да пишат документация.
48. МИТ
49. Некадърните програмисти мразят да пишат документация.
50. Разликата между успешен и неуспешен проект често е в документацията.
51. Нива на документация • Огромно README - задължително! • API документация - задължително за библиотеки! • Changelog - силно препоръчително! • Community Wiki - препоръчително • User manual / Tutorials / etc - препоръчително
52. Changelog
53. • Не трябва да е копие на commit history • Разделяйте на групи като “new features”, “changes” & “bug fixes” • Добре е поставяте връзки към issue tracker-а в него • Потребителите са суетни - отбелязвайте заслугите им поименно
54. Contribution Guidelines
55. Повторението е майка на познанието друг път…
56. Правила • Формат на комитите • Workflow правила • Указания за стила на кода • Общи правила
57. Continuous build
58. TravisCI
59. Versioning Scheme
60. Semantic Versioning (semver.org)
61. 3.14.1 ! MAJOR.MINOR.PATCH
62. Release early, release often
63. Feedback-a от early adopters е crucial
64. Плащайте си техническия дълг редовно!
65. Пътят от novelty до legacy е по-кратък отколкото си мислите.
66. Не времето прави код “legacy”, а липсата на адекватна поддръжка.
67. Комуникация
68. Issue Tracker
69. Mailing list
70. Twitter
71. Support Forum
72. Промотиране на творчеството ви
73. Без потребители в света ще е скучно…
74. Онлайн • Twitter • Специализирани портали (e.g. RubyFlow) • Reddit • HackerNews • Google+ • Facebook
75. Взаимоотношения с потребителите
76. • Уважавайте техните желания. • Игнорирайте пропуските в английският им. • Давайте им насоки как да докладват проблеми по оптимален начин. • Оправяйте докладваните от тях проблеми срочно. • Ако изявят желание да се борят с проблем - насърчете ги да го направят.
77. Отношение към contributions
78. • Отнасяйте се с уважение към всеки PR. • Дискутирайте и ревюирайте всеки PR. • Дръжте на това всеки PR да съответства на утвърдените за вашия проект норми. • Поощрявайте значимите приноси по проекта. • Култивирайте си заместник-шерифи.
79. Отворностите никога не свършват
80. Контакти • http://batsov.com • bozhidar@batsov.com • @bbatsov
81. Felina