The Zen of Python

    Beautiful is better than ugly.
    Explicit is better than implicit.
    Simple is better than complex.
    Complex is better than complicated.
    Flat is better than nested.
    Sparse is better than dense.
    Readability counts.
    Special cases aren't special enough to break the rules.
    Although practicality beats purity.
    Errors should never pass silently.
    Unless explicitly silenced.
    In the face of ambiguity, refuse the temptation to guess.
    There should be one-- and preferably only one --obvious way to do it.
    Although that way may not be obvious at first unless you're Dutch.
    Now is better than never.
    Although never is often better than *right* now.
    If the implementation is hard to explain, it's a bad idea.
    If the implementation is easy to explain, it may be a good idea.
    Namespaces are one honking great idea -- let's do more of those!

(PEP 20)

Christopher Groskopf

550

I think the size and mix of a team really depends on who is involved and how ambitious you (or the people with the purse strings) want to be. At the end of the day you're building a project, which requires some combination of design, journalism, and coding. Either you have all those skills within your team or you find yourself collaborating with others (or faking it).

For me, two people is often an ideal team size for an individual project. With two people you're likely to cover all three skill sets without having cut corners or rely on skills (and schedules) outside the team. You can have one person focusing on the [technical details of] the backend, another person focusing on the [technical details of] the frontend, and both people cross-checking the how/why/is-it-accurateness of the entire application.

(Of course, I think everyone who claims two or more of the hacker/journalist/designer labels has found themselves in a team-of-one position simply by virtue of combining the two skills they do have (say, journalism and coding) with some good old fashioned faking it. I know I have.)

Brian Hamman

115

The applications at projects.latimes.com allow comments using our fork of Django's contrib.comments application. I'm pleased to report that the authorization bizness comes out of the box.

The results aren't always great, but they can occasionally move you in a way that no metadata ever could.

A plus of a Django fork is that you can save your energy for tricking out the codebase with new features. We've experimented with "geo-comments" where readers submit custom maps and reporter-written "responses" (click here, flip to the comments and ctrl-F for "Scott Gold") that allow for our staff to participate.

Ben Welsh

110

Short answer: Building things > reading things.

Longer answer:

Working on and helping build a community site helped me understand what was possible with a well-structured database, and the importance of making things useful for users.

Adrian Holovaty's essay on fundamental change in thinking about news drove that point home. Once I started learning Django, I started to see structure in all sorts of random bits of information. This talk by Derek Willis gets to a lot of that as well.

In the course of building Patchwork Nation, I started thinking about how databases and web applications could work as reporting tools, which became the basis for my thinking on frameworks for reporting.

Failing helps, too.

But there is plenty worth reading:

• Teaching Online Journalism
• How to Think Like a Computer Scientist
• The Django Book

Also, I'm a big fan of the Zen of Python. When you start using that to give your housemate relationship advice, you've crossed some kind of threshold.

Chris Amico

785

One of the secrets of my team's success is that I can sell. Not just pitch, but bring a product to market. If that doesn't fit within your organizational structure, I strongly recommend making strong ties with someone in your organization who can put a price tag on something and bring back signed contracts or checks.

joeboydston

20

If you had each app in a separate database, I wonder if you could use something like Disqus or Intense Debate and their respective APIs to pull in everything across the site (or many sites). The problem, of course, is where to put comments and what purpose they serve.

What I really like about the way the Ben's apps at the LA Times have done is the way they've used comments and feedback as part of the app. The "Share a Memory" prompt on the War Dead really set it apart from all the other similar databases and did a lot to keep things human.

Chris Amico

785

We looked at using Processing in the past and found it was a great language, easy to achieve good results. The main point against it back then was the fact it was Java, as loading an applet in browsers was just far too slow. However there is now the Processing.js project, which is aiming to implement as much of of Processing as possible using Javascript and HTML 5 canvas. It currently has limited browser support, but can be made to work well on mobile platforms which might be an advantage over flash.

julianburgess

30

In our (very beta) news-ish app which puts readers directly in touch with homeless individuals, who can use these profile pages as an unfiltered blog, we've just integrated it with the rest of our sites structure.

I think this is one of those equestions where the unfortunate answer is, "It depends." What are you trying to accomplish with the comments? And why would it be on a different authentication system?

For a news app like Gotham Gazette's "Budget balancer," I think a really useful "comment" system would be to allow people to pose their budget proposals publicly with maybe a little commentary. More general comments, on the other hand, likely wouldn't have added much value beyond shouting matches.

Michael Morisy

241

There ought to be a manager, though not necessarily as a separate person with only that role (in fact, that's probably not the way to go about it). At the end of the day, there should be someone who can make sure people are staying on task, set deadlines when they need to be set, and be clearly responsible for making the calls the group might not be able to make as a whole.

Personally, I'd stay away from having a group of more than three or four working on any one project if possible. Coordinating more schedules than that can get unwieldy rather quickly, and it's easier to keep everybody feeling more or less equal rather than like part of a big hierarchy. (Plus, it's easy to fit the entire team around a table for drinks.)

As for specific skills, I think Brian nailed it--it all depends on the project and how much you and your team want to be able to do on your own.

Justin Myers

0

We use Pluck for comments. It integrates in a lightweight way, the user data is stored by us, we just give Pluck a user name, and sign a cookie to authenticate.

julianburgess

30

No way to put it better than Brian:

For me, two people is often an ideal team size for an individual project. With two people you're likely to cover all three skill sets without having cut corners or rely on skills (and schedules) outside the team. You can have one person focusing on the [technical details of] the backend, another person focusing on the [technical details of] the frontend, and both people cross-checking the how/why/is-it-accurateness of the entire application.

That's definitely my favorite way to work, and how we generally try to tackle projects here at the Spokesman.

Ryan Pitts

95