You can overdress in a way that still makes it super obvious you're not being "dressy". Unconventional accessories are always a good pick.
Like, you can be wearing the nicest of tuxedo pants with the nicest of button-down shirts, but adding just the right hat or scarf magically turns it into a casual outfit.
Agreed. As someone who wears a fedora regularly (actually a black Akubra Hampton), it gets a very different reaction depending on the context. I've been stopped on the street once by someone who said "Cool hat! So you're a Bronie right?" You don't want that.
But when I'm travelling overseas, it gets a much more positive and inquisitive reaction. Many times people have used the hat as an ice-breaker to start an interesting conversation with me. And if you're the only person with a hat in a group, it can be helpful branding so people recognize & remember you.
Interesting. My experience in the US has very much been the latter. What do you typically wear with it? I definitely think it says different things with slacks and a sport coat then jeans and a hoodie.
Nope, from the wp article: "The bus factor is the total number of key developers who would need to be incapacitated [...] to send the project into such disarray that it would not be able to proceed"
Note that often (e.g. when comparing bus factor of projects of different sizes) it makes sense to normalize by dividing by the size of the team in which case the answer to asogi's question is "Yes, normalized bus factor is 1/n"
> when comparing bus factor of projects of different sizes [] it makes sense to normalize by dividing by the size of the team
Consider two projects, a one-man project with a bus factor of, obviously, 1, and a 100-man project with so much redundancy within the group that the bus factor is an impressively robust 50. The standard bus factor immediately tells us that the big project is much much less fragile.
The "normalized bus factor" you describe (1 for the solo project, 1/2 for the huge project) perversely tells us that the big project is much more fragile, in that it will be disabled by the loss of 50% of the team, while the solo project will only go down after a full 100% of the team is eliminated.
Why does it make more sense to count redundancy by "percentage of the team, whatever size the team might be" rather than by "number of setbacks before project failure"? In general, the bigger team really does make the project more robust, not less robust.
Hm. I wonder if there's a way to distinguish between "If this particular person gets hit by a bus, we're screwed" versus "If any of these n people get hit by a bus, we're screwed" (which is a lot worse).
How about looking at the number of people who must be removed in order to bring the bus factor down to 1? We can call it the "bus co-factor" :). With the bus factor we're picking the most critical people first, and removing the least number of them; with the bus co-factor we're picking the least critical people first, and removing the greatest number of them.
There's probably already some name and many theorems in graph theory for both of these ideas.
You can treat it like a reverse big-O notation. Your figure out the bus factor for each sub-task/system in your project (this is the risk factor) and then determine the priority of each sub-task/system. If a GUI is "easy" or low priority for your project, one GUI person doesn't mean your project has a bus factor of 1. But if networking is critical and you have one person that understands the novel telecon protocol stack you're using, that's a bus factor of 1.
So, now that the zip file is missing from GitHub, some people are starting to upload it elsewhere. Can the people who got it from GitHub earlier post the result of running
md5 Atom.zip
? That might help mollify the paranoid conscience.
(EDIT: or any other hash function for that matter.)
I think the atom.zip is being updated continuously. Today I finally got my invitation and it gives a different shasum too. File diff shows the Info.plist of my newly downloaded version as of 2014-03-07 is:
