1. 3

    I personally don’t enjoy working in war rooms. To me they indicate a failure of process. If you needed to get everyone together in a room to solve a problem, why isn’t your office laid out in that fashion in the first place? This assessment is colored by my past experiences with war rooms in which it was a mad dash to the finish line featuring late nights and little sleep. It sounds like your war room process is just a change of scenery, which is much better.

    1. 2

      why isn’t your office laid out in that fashion in the first place?

      I would imagine that these groups are amorphous, and change all the time.

      1. 1

        Exactly the reason all of Valve’s desks have wheels. http://boingboing.net/2012/04/22/valve-employee-manual-describe.html

      2. 1

        Author of the article here.

        I can sympathize with your negative experience – I’ve been there too. I think that a key difference between whether the experience sucks or not, is whether a self-organizing team chooses to head to the war room or if a manager sends you there.

        Also, at Braintree (and the last two places I worked) we did always have everyone needed to solve the problem in one room. The issue is that there are lots of other people and teams around in an open floor plan environment with a larger team. So the war room is a way of taking a subset of the team off to concentrate on a problem with fewer distractions.

      1. 1

        I really don’t know how I worked without jQuery.maskedInput…

        1. 1

          Ironically, even though I mention it in the blog post, I haven’t had a chance to put Masked Input to work in practice yet. I came across it while wrestling with this post. I need to figure out if it can wait to display the masking characters until the user enters text – this would mimic the iPhone style data entry experience for users.

        1. 6

          This could just as easily be titled “How to get anyone to help make your open source project awesome.”

          If I can’t tell what your project does from its homepage/Github repo, I’m probably not going to try it out. Link to a demo or show some screenshots or something.

          If your project is hard to install or has lots of hidden dependencies, I’m probably going to give up halfway through reading about it. I resisted using Graphite because the setup seemed really daunting.

          If your project has some arcane bug tracking system that makes me jump through hoops of creating an account, waiting for a verification e-mail, filling out captchas, and then filling out tons of form fields just to report a bug, guess what, I’m not going to bother reporting the problem.

          1. 1

            I agree. It’s important to at the very least provide links to tutorials or project pages for the languages/tools used to develop the project so others can get a development environment setup. I do think this point is more important for designers since more often than not they are unfamiliar with the tools used to build open source projects.

            1. 1

              I do think this point is more important for designers since more often than not they are unfamiliar with the tools used to build open source projects.

              @b this is exactly what I was getting at in the blog post, but I agree with @jcs that things that make it easier for designers to get involved with a project should make it easier for anyone to get involved.