diff options
| -rw-r--r-- | spm-slides.tex | 99 |
1 files changed, 4 insertions, 95 deletions
diff --git a/spm-slides.tex b/spm-slides.tex index d013e18..e406011 100644 --- a/spm-slides.tex +++ b/spm-slides.tex @@ -1343,6 +1343,9 @@ of each software source file. \end{verbatim} } + +{\em Copyleft}. A copyleft license says that the derivative works must grant freedoms described in the parent license. + %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \foilhead{Good precedents} @@ -2823,98 +2826,4 @@ Humans have a {\em built-in desire} to work with other humans, and to {\em give \underline{Delegation}. Ask someone else to take on the task. Purpose: not just about getting individual tasks done, but also drawing people into a closer commitment to the project. -Make the assignment of a task (ticket) in the form of an inquiry. - -{\tiny -\begin{verbatim} - Assigning this over to you, jrandom, because you're most familiar with this code. Feel - free to bounce this back if you don't have time to look at it, though. (And let me know - if you'd prefer not to receive such requests in the future.) -\end{verbatim} -} - -\underline{Follow up after you delegate}. - -\underline{Notice what people are interested in}. The more aware you are of what different people want out of the project, the more effectively you can make requests of them. Demonstrating an understanding of what they want in itself is useful. - -\underline{Praise and criticism}. Both show attention. Be specific rather than generic. Both can be diluted by inflation. Detailed, dispassionate criticism is often taken as a kind of praise. Most people respond pretty well to criticism that is specific, -detailed, and contains a clear (even if unspoken) expectation of improvement. - -\underline{Prevent territoriality}. When people sense a "no trespassing" sign, they stay away. For example, author names. - -\underline{The automation ratio}. - -\underline{Automated testing}. Regression testing, regression test suite, regression. Unit testing, a unit test suite. - -% skip: Treat Every User as a Potential Participant - -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -\foilhead{Share management tasks} - -"Manager" does not mean "owner". {\em Responsibility without monopoly}. What should we do in case of conflict: two or more people want the same role? - -Patch manager. Translation manager. Documentation manager. Issue manager. - - -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -\foilhead{Transitions} - -Personal circumstances can change. - -{\tiny -\begin{verbatim} -> If you wish to replace me with some one else, I will gracefully -> pass on the role to who comes next. I have one request, which -> I hope is not unreasonable. I would like to attempt one more -> release in an effort to prove myself. - -I totally understand the desire (been there myself!), but in -this case, we shouldn't do the "one more try" thing. -This isn't the first or second release, it's the sixth or -seventh... And for all of those, I know you've been dissatisfied -with the results too (because we've talked about it before). So -we've effectively already been down the one-more-try route. -Eventually, one of the tries has to be the last one... I think -[this past release] should be it. -\end{verbatim} -} - -The most important factor in asking someone to step down is privacy: giving him the space to make a -decision without feeling like others are watching and waiting. - - -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -\foilhead{Committers} - -A committer is someone who has commit access: the right to \underline{make changes} to the copy of the code that will be used for the project's next official release. - -A committer has the ability to put changes into the {\em master} copy. - -There are always many people who feel competent to make changes to a program, and some smaller number who actually are. - -How to choose a committer? The Hippocratic Principle: {\em first, do no harm}. Good judgment. Good personality. - -If you have 100 committers, 12 of whom make large changes on a regular basis, and the other 88 of whom just fix typos and small bugs a few times a year, that's still better than having only the 12. - - -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -\foilhead{Credit} - -Credit is the primary currency of the free software world. - -Participation in an open source project can indirectly have monetary value, because many employers now look for it on resumés. - -When small contributions are acknowledged, people come back to do more. - -Keep accurate records of who did what (be specific), when. - -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -\foilhead{Forks} - -"Social forks" versus "short forks (hard forks)". - -\underline{Handling a fork}. A social fork is not necessarily a bad thing (e.g., GCC/EGCS fork). Keep calm and remember your long-term goals. Don't remove someone's commit access in your project just because she decided to work on the fork. - -\underline{Initiating a fork}. {\em Most forks do not succeed, and most projects are not happy to be forked}. Take all factors into account in evaluating the potential success of your fork. Line up support privately first, then announce the fork in a non-hostile tone. Granting all committers of the original project commit access to the fork, including even those who openly disagreed with the need for a fork. - -\end{document} +Make the assignment of a task (ticket) in the form of an inquiry
\ No newline at end of file |