I put “how well” and “how much” in the “more is better” bucket, so I will definitely tackle these immediately after the “must be” stuff. But I agree that there is some level of performance that “must be” – will manage that as we go.

My plan, since we’re learning Rails as part of this project is to

1)set up deployment infrastructure (instantRails, svn, etc)
2)create a VERY rough prototype and deploy it
3)work out the change management process (iterate the prototype and deploy the update)
4)start tackling performance stats, etc. If there are performance issues with a handful of users, that speaks to really bad design on my part – will open up to maybe 10 people to “bang on” the first iterations, and grow the user base as the site gets more functional. I suspect there are great perf-tracking products/gems for rails, I just don’t know what they are yet.

Your suggestions on specific things to look at for response times are great ones – will definitely include them.

For example, for me it is very important that all the small interactions with the site, like rating, suggesting, searching, show their results extremely fast. I can wait a little longer for an article to be loaded.
Another example would be reliability: I’d like to see my comments right away.
Or, the sheer amount of articles should not cause the site to slow down. I’d like to see the pages using bandwidth economically, as I will sometimes use my mobile phone.

The only one I had come up with so far was contact settings for communication between users. I’ve represented this as an enumeration in my domain model (UML Static Diagram), and I expect to describe it as a requirement – “user can specify contact level (see list of choices).”

Thanks for starting this thread!