Hi again, This is a follow-up to the adventure branch thread. I hope I've managed to keep this as short and painless as possible.
I think there are three discussions practices which we either need to adopt or to return to: 1. Make decisions on darcs-users 2. Keep discussions open-ended 3. Lead by example Make decisions on darcs-users ---------------------------------------------------------------------- We need to be careful to make our decisions in public and the most public place to do this is darcs-users, not during hacking sprints, and not on the IRC channel. First: it creates good atmosphere. People can be turned off by the impression that decisions are made by some sort of secret cabal, which can be a big turn-off for folks. This is why we must be patient with the sometimes lengthy discussions, consultation processes and consensus-based decision making. It may be slow and painful in the short term, but in the long run, it will us to maintain a healthy pool of contributors which ultimately helps us to make faster progress. Second: it helps us make better decisions. Yes, sometimes things can descend into bikeshedding; but this side-effect can be mitigated with a bit of discussion management. Having a wide range of perspectives makes us stronger because it helps us get novel insights into whatever problem we're trying to solve. As a concrete example, consider the case of deprecating old-fashioned repositories. Would we have remembered optimize --upgrade if Dan had not spoken up and said that "if you want to support get, you must support pull?" We can always use a different way of looking at things. Karl Fogel explains this very nicely, so I'll refer you to his chapter for other reasons we want to be careful about public decision-making [1]. IRC and face-to-face discussions are brilliant thinking tools and we should continue to use them; however, they can also exclude potential participants who are on site at the time. The #darcs channel in particular has some nice logs to mitigate the exclusion, but logs alone do not give people a chance to provide feedback. So we should not only be disciplined about following up on discussions with a link to the log, but also generally having that attitude that no discussion is official until it's on darcs-users. Keep discussions open-ended ---------------------------------------------------------------------- Petr's email was a nice summary of the adventure branch, but it sounded too more like a fait accompli than the opening of a discussion. As a corollary to the "make decisions on darcs-users" idea, we should pay more attention to the spirit in which we write our proposals. Part of making decisions publicly is to make it clear where discussions can be open-ended. So this is not a wise move, except at the end of a discussion: We have decided to X using Y and Z Petr's email was more better because it presented a proposal: We discussed X and I propose Y with Z rules Perhaps something more open-ended would have been better? We would like your help on X problem. One possible solution is Y with Z rules, but are there other ways of solving X? I think it's more efficient to aim for this sort of open-endedness. It may slow us down in the beginning, but as I claimed above it also makes for good long-term hygiene and provides for new insights from different perspectives. On a shorter term, it's also beneficial because it helps to avoid any sort of "ARGH, why wasn't I consulted?!" overreaction, not to mention all the ink that gets spilled as a reaction to that. Making things open-ended from the get go is not only healthier but faster. Lead by example ---------------------------------------------------------------------- There's a story in Producing Open Source Software about how Greg Stein managed to create a patch review culture in the Subversion project [2]. He did this not by trying to telling developers they needed to review patches more; that's something they already "knew" was a good habit that they "ought" to be taking up. How did Greg break the inertia? He just started systematically reviewing every patch that came into the mailing list, occasionally stopping to point out where this was concretely beneficial. And eventually it just sort of caught on and became a habit. Following one anecdote with another, the New York Times Magazine recently did a piece about teaching school teachers to be more effective [3], with one particularly striking example being Bob Zimmerli's classroom control: Zimmerli stands at the front of the class in a neat tie. "O.K., guys, before I get started today, here’s what I need from you," he says. "I need that piece of paper turned over and a pencil out." Almost no one is following his directions, but he is undeterred. "So if there’s anything else on your desk right now, please put that inside your desk." He mimics what he wants the students to do with a neat underhand pitch. A few students in the front put papers away. "Just like you’re doing, thank you very much," Zimmerli says, pointing to one of them. Another desk emerges neat; Zimmerli targets it. "Thank you, sir." "I appreciate it," he says, pointing to another. By the time he points to one last student -- "Nice . . . nice" -- the headphones are gone, the binder has clicked shut and everyone is paying attention. While I imagine that the art of teaching is far more trickier and subtler than this one anecdote could possibly convey, I do think that there is truth to the idea that if you want to change people's behaviours, you need to focus on specifics, not the desired outcome (more tests) but the nitty gritty details of getting to that outcome (exactly how to write these tests). That's two different senses of leading by example. First, if we care deeply about changing a culture, we need somebody to act as a good example, not just to say "We should do X" (if nothing else because it often just sounds like "*I* think *you* should do X") , but to actually do X and to keep doing X until people start to see the light and follow your lead. That's leading by example. Second, if we care about getting people to behave in a certain way, we need to give them good examples of what exactly such behaviour entails; saying "we should do X" may not get us very far, but actually showing us how to do it could be more successful. And that's leading by examples. Conclusion ---------------------------------------------------------------------- Sorry for the lecture! I certainly have trouble with a couple of these things: I tend to abuse hacking sprints to make quick roundtable discussions and also to bang-on-drums and go rah-rah more than provide a concrete example to work from, so I understand this isn't easy. To be clear, I'm most certainly not asking for a flowers-and-candy approach to writing here. Direct and to the point is way better than the sort of gushing or "nice" or sentimental. But if we can stick to these sorts of principles -- making decisions on darcs-users, keeping discussions open-ended and leading by example -- I think we'll make faster progress in the long term. Worth a shot, maybe? Eric [1] http://producingoss.com/en/setting-tone.html#avoid-private-discussions [2] http://producingoss.com/en/producingoss.html#code-review [3] http://www.nytimes.com/2010/03/07/magazine/07Teachers-t.html -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> For a faster response, try +44 (0)1273 64 2905 or xmpp:ko...@jabber.fr (Jabber or Google Talk only)
signature.asc
Description: Digital signature
_______________________________________________ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
