exactly sure why it works. I have my suspicions. But, since can’t start a control DXR & and experimental DXR & run one of them under an assumed name. …this is going to be a mixture of interviews and personal experience from various projects. & I hope you’ll jump in with yours as we go.
as being intrinsically interesting. Lucked out. Blessed by gods of interestingness. Static analysis is neat. Not CRUD. & certainly contributors responded to that. But interestingness is one example of an apparently intrinsic property which can actually be manipulated. What may appear to be an uninspiring project may not be, if you just broaden your search. Go ahead, put some crazy ideas on a page somewhere, and let the motivated contributor chase the unicorn. They may deliver! e.g. Explosive crashes.
learn more about static analysis.” I always thought of DXR as being intrinsically interesting. Lucked out. Blessed by gods of interestingness. Static analysis is neat. Not CRUD. & certainly contributors responded to that. But interestingness is one example of an apparently intrinsic property which can actually be manipulated. What may appear to be an uninspiring project may not be, if you just broaden your search. Go ahead, put some crazy ideas on a page somewhere, and let the motivated contributor chase the unicorn. They may deliver! e.g. Explosive crashes.
was] wanting to learn more about static analysis.” I always thought of DXR as being intrinsically interesting. Lucked out. Blessed by gods of interestingness. Static analysis is neat. Not CRUD. & certainly contributors responded to that. But interestingness is one example of an apparently intrinsic property which can actually be manipulated. What may appear to be an uninspiring project may not be, if you just broaden your search. Go ahead, put some crazy ideas on a page somewhere, and let the motivated contributor chase the unicorn. They may deliver! e.g. Explosive crashes.
tagged as easy to start with—that’s what made me look at the vagrant thing and think, oh, i can do that no problem.” Another intrinsic: existence of “easy” bugs. low-hanging fruit. What if your project doesn’t have any, or they’re all boring? DXR is, again, lucky: everything could be better, and we file tickets about how. But you can actually create this situation. I actually make a point of getting lower priority things just fixed enough so user can get their work done and then ticketing the remaining polish as an "easy".
using, and I wanted it to be better.” A final handy happenstance our audience is well-equipped to contribute. Our audience is big. Wide applicability: everybody has code to reason about. Not everybody wants to publish their code on GH. You can widen your audience, enlarging your pool of potential contributors. Make it scale up, scale down. Make it easy to get your first use out of it: full text search, no matter language. Not much config. Good docs.
a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.” —Antoine de Saint Exupéry «quote» A pile of bugs never does it for me. I have to have some kind of Grand Idea I’m working toward. ▼ ❑ So, for myself & others… • ❑ Oh my god, look what this could be. ▼ ❑ Important to do that planning in the open. UI_Refresh wiki page
didn't think of. • ❑ Low-fi ones don't often engender the same excitement [in me] as hi-fi ones. • ❑ Catch holes in thought. Avoid wasted effort. • ❑ Okay to put up ones that are bad. Say what’s still bad. ▼ ❑ Draw your priorities from your customers. • ❑ But it's not a democracy. ▼ ❑ Sometimes it's your job to do what's best for the customer in spite of the customer's direct request • ❑ e.g. Everybody asked for a link to docs for the query language • ❑ What we actually did was put the filters into a menu and put explanations in there. • ❑ "A faster horse". Listen to the pain, not the self-diagnosis. ▼ ❑ Loudly solicit input. • ❑ Thinking of trying Mozilla Moderator ▼ ❑ But the point is: Figure out where your customers live, and talk to them there. • ❑ I started out on the dev-static-analysis list. Nobody reads that. • ❑ Turns out my users live on dev-platform. ▼ ❑ Their attention is a precious resource • ❑ I post only when I have super good news (major features) or want major input. • ❑ Don't desensitize them by posting weekly updates, and for HELL's SAKE don't title them "DXR Weekly Update 2/4/2014". • ❑ I always get at least 5 or 6 responses. • ❑ The community likes the blog; the FF devs like the mailing list. Crossposting ftw. ▼ ❑ Object: understand their needs. Ask for use cases when they're not obvious. • ❑ Then determine priorities. • ❑ And don't bury them in bugs. It's so hard to suss out anything from a big bag of bugs. ▼ ❑ Instead, publish large, guiding goals (a form of vision casting, if you will) as a
didn't think of. • ❑ Low-fi ones don't often engender the same excitement [in me] as hi-fi ones. • ❑ Catch holes in thought. Avoid wasted effort. • ❑ Okay to put up ones that are bad. Say what’s still bad. ▼ ❑ Draw your priorities from your customers. • ❑ But it's not a democracy. ▼ ❑ Sometimes it's your job to do what's best for the customer in spite of the customer's direct request • ❑ e.g. Everybody asked for a link to docs for the query language • ❑ What we actually did was put the filters into a menu and put explanations in there. • ❑ "A faster horse". Listen to the pain, not the self-diagnosis. ▼ ❑ Loudly solicit input. • ❑ Thinking of trying Mozilla Moderator ▼ ❑ But the point is: Figure out where your customers live, and talk to them there. • ❑ I started out on the dev-static-analysis list. Nobody reads that. • ❑ Turns out my users live on dev-platform. ▼ ❑ Their attention is a precious resource • ❑ I post only when I have super good news (major features) or want major input. • ❑ Don't desensitize them by posting weekly updates, and for HELL's SAKE don't title them "DXR Weekly Update 2/4/2014". • ❑ I always get at least 5 or 6 responses. • ❑ The community likes the blog; the FF devs like the mailing list. Crossposting ftw. ▼ ❑ Object: understand their needs. Ask for use cases when they're not obvious. • ❑ Then determine priorities. • ❑ And don't bury them in bugs. It's so hard to suss out anything from a big bag of bugs. ▼ ❑ Instead, publish large, guiding goals (a form of vision casting, if you will) as a
lot of yearning for the endless sea out there. • ❑ All I have to do is «don't crush their dreams». • ❑ Sometimes I have to slightly steer their ambitions. • ❑ But I try not to say "no, that's dumb" to anybody. • ❑ Instead, say "How about this instead?" The interesting thing is you don't have to be definitive or even knowledgeable. All you have to be is communicative. Just treat everybody like adults and articulate your fears. I've said "I'm happy you want to work on that, but here are my fears: merge hell, bad UI, slow perf, whatever." Inviting them into the tradeoff is a heckuva lot better than a booming "no!".
• ❑ There's already a lot of yearning for the endless sea out there. • ❑ All I have to do is «don't crush their dreams». • ❑ Sometimes I have to slightly steer their ambitions. • ❑ But I try not to say "no, that's dumb" to anybody. • ❑ Instead, say "How about this instead?" The interesting thing is you don't have to be definitive or even knowledgeable. All you have to be is communicative. Just treat everybody like adults and articulate your fears. I've said "I'm happy you want to work on that, but here are my fears: merge hell, bad UI, slow perf, whatever." Inviting them into the tradeoff is a heckuva lot better than a booming "no!".
to get help and make progress, not so many that you’re fighting over bugs and duplicating work.” Trying to figure this out last night, I talked to my people. A couple interesting things popped out. One of which… Community Size «quote»
that there are people in #static” ▼ ❑ Number of people • ❑ Like the amount of stuff on a shelf creates demand. • ❑ Fill your channel with bots, and talk through them to simulate community. Fake it till you make it? ;-) How to control size or make it feel like a right-size community?
a great thing about working on DXR— helpful and motivating :-)” “The IRC channel is probably a big thing. It’s nice to get quick feedback on questions. And a lot less formal/intimidating than a mailing list that you’ve never read before. IRC People really value it. • ❑ I don't always have the answers, but I'll often answer anyway, even if just to say "I've had that blow up inexplicably for me, too. Maybe flip the switch back and forth and see if that helps?” Then they usually solve their own problem, but they feel like they're not in it alone. • ❑ I think it's the same reason I find it satisfying to rubberduck into an idle IRC channel. It feels good to be “in it together.” Am I the only one who does that?
contribs. & that snowballs. ▼ ❑ abbeyj • ❑ works for a financial software house that sells their wares to quant firms and such • ❑ C++ maniac • ❑ Finds all the corner cases (in production code, he assures me) and fixes them • ❑ Submits bulletproof unit tests • ❑ First non-paid commit-bit haver ▼ ❑ nrc • ❑ Recently joined the Rust team • ❑ Has DXR Rust analysis almost ready to go ▼ ❑ jamon • ❑ New in the last 2 weeks • ❑ Sysadmin by day • ❑ Already fixed our Vagrant issue on Jenkins • ❑ Implemented multi-region highlighting ▼ ❑ Mook • ❑ from ActiveState • ❑ Lots of great tweaks for running under PaaS ▼ ❑ espressive • ❑ Totally rewrote all our janky JS and most of our CSS • ❑ Got me back into front-end ▼ ❑ fubar • ❑ Ops with a smile Make it the kind of environment where those kind of people want to be. Once you have those ppl care & feeding has to be a high priority.
pain points Again, don’t crush their dreams ▼ ❑ [e.g.] We review patches within a day or 2 and push them as soon as it isn't utterly irresponsible. • ❑ If something's wrong with a patch, we tell them before they've forgotten all about it. • ❑ Also, People get to see the fruits of their labors fast. • ❑ Some people's ambitions are as simple as "I wish to contribute to this project". They don’t last. ▼ ❑ Don't frustrate new contribs by nitpicking them to death. • ❑ If you want to maintain clean code, just stack your own cleanup commit atop theirs the first time around, then merge their branch. • ❑ If they turn into a repeat contributor, start shepherding them toward cleaner code. This saves your time on one-timers. • ❑ I treat it like a "level up" sort of thing: this time, I'll take the code without tests. Next time, I think you're ready to include tests. Here, I've added a test for your code as an example. ▼ ❑ I dish out an awful lot of git help, largely untangling accidental or ill-thought-out merges. It's too bad GH is so good, or we could use something more usable. • ❑ I have lost contribs on my other projects because of git. They've forked rather than cherry-pick themselves out of the mess they got into. • ❑ What can we do about that? ▼ ❑ Thank them. Publicly. Every time you do a communication. Rebuke privately. ▼ ❑ You may not have money, so give them other things. • ❑ EDIT_BUGS perm
Make sure you fix developer pain points Again, don’t crush their dreams ▼ ❑ [e.g.] We review patches within a day or 2 and push them as soon as it isn't utterly irresponsible. • ❑ If something's wrong with a patch, we tell them before they've forgotten all about it. • ❑ Also, People get to see the fruits of their labors fast. • ❑ Some people's ambitions are as simple as "I wish to contribute to this project". They don’t last. ▼ ❑ Don't frustrate new contribs by nitpicking them to death. • ❑ If you want to maintain clean code, just stack your own cleanup commit atop theirs the first time around, then merge their branch. • ❑ If they turn into a repeat contributor, start shepherding them toward cleaner code. This saves your time on one-timers. • ❑ I treat it like a "level up" sort of thing: this time, I'll take the code without tests. Next time, I think you're ready to include tests. Here, I've added a test for your code as an example. ▼ ❑ I dish out an awful lot of git help, largely untangling accidental or ill-thought-out merges. It's too bad GH is so good, or we could use something more usable. • ❑ I have lost contribs on my other projects because of git. They've forked rather than cherry-pick themselves out of the mess they got into. • ❑ What can we do about that? ▼ ❑ Thank them. Publicly. Every time you do a communication. Rebuke privately. ▼ ❑ You may not have money, so give them other things. • ❑ EDIT_BUGS perm
developer pain points Again, don’t crush their dreams ▼ ❑ [e.g.] We review patches within a day or 2 and push them as soon as it isn't utterly irresponsible. • ❑ If something's wrong with a patch, we tell them before they've forgotten all about it. • ❑ Also, People get to see the fruits of their labors fast. • ❑ Some people's ambitions are as simple as "I wish to contribute to this project". They don’t last. ▼ ❑ Don't frustrate new contribs by nitpicking them to death. • ❑ If you want to maintain clean code, just stack your own cleanup commit atop theirs the first time around, then merge their branch. • ❑ If they turn into a repeat contributor, start shepherding them toward cleaner code. This saves your time on one-timers. • ❑ I treat it like a "level up" sort of thing: this time, I'll take the code without tests. Next time, I think you're ready to include tests. Here, I've added a test for your code as an example. ▼ ❑ I dish out an awful lot of git help, largely untangling accidental or ill-thought-out merges. It's too bad GH is so good, or we could use something more usable. • ❑ I have lost contribs on my other projects because of git. They've forked rather than cherry-pick themselves out of the mess they got into. • ❑ What can we do about that? ▼ ❑ Thank them. Publicly. Every time you do a communication. Rebuke privately. ▼ ❑ You may not have money, so give them other things. • ❑ EDIT_BUGS perm
erikrose
free_world21
hironytic
kosmosebi
schroneko
polamjag
akidon0000
stewemetal
bob3bob3
riofujimon
lovee
memory1994
faithandbrave
chriscoyier
lauravandoore
lara
jnunemaker
samlambert
sachag
morganepeng
trallard
speakerdeck
dougneiner
afnizarnur
iamctodd
![intrinsics & gaming them intrinsics “[My motivation was] wanting to](https://files.speakerdeck.com/presentations/bf33c040fb1801314e265e72313fb849/slide_3.jpg){kind=link}
