Skip to content
This repository has been archived by the owner on Feb 9, 2021. It is now read-only.
kynan edited this page May 28, 2012 · 9 revisions

Welcome to the checklisthq.com wiki!

User stories can be found here.

Why Checklists are important can be found here.

What do I do..?

I'm a developer

We're using Django (see http://djangoproject.com) as the web framework. If you've never used Django before, pair up with another developer who has. Pair programming is fun and a great way to learn new technology. Otherwise, follow these steps:

Doing a code review on a pull request is not primarily for feedback (although that is useful). Rather, it's a means of spreading knowledge about how the application works among the group. If you fancy a brain-break, do a code review and shout when it's ready to be merged..!

Did I mention tests are good..? No..? Well, we should write tests! :-)

I'm a designer

You'll be absolutely thrilled to bits to hear that the experimental site we built earlier this week uses vanilla twitter/bootstrap (see: http://twitter.github.com/bootstrap/index.html). We very much want this thing to work well so an emphasis on UX rather than UI is perhaps the order of the day (i.e. answering questions like "what button should go where?" rather than "what colour should the button be?") - but if you want to "design" please use the less source code from bootstrap.

Ask for a guided tour of the HTML templates. Django's templating language is explained here: https://docs.djangoproject.com/en/1.4/topics/templates/

I'm a doctor

Wai Keong is the doctor person you're looking for.

Some things spring to mind:

  • Improve the user stories.
  • Tell a designer what works and what doesn't when they're producing mock-ups.
  • If a developer wants to demo something, tell them what's wrong and suggest how to fix it.
  • If something is broken submit an issue by clicking on the "New Issue" button on this page: https://github.com/checklisthq/checklisthq.com/issues

You'll be a developer's best friend if you remember to do the following when submitting an issue:

  • Give a brief description. (e.g. "Checklist editing doesn't work")
  • Explain what you expected to happen. (e.g. "When I clicked the 'submit' button I expected my checklist to be saved")
  • Describe what actually happened (e.g. "Instead, I got some sort of error message. '500 Internal server error'")
  • If possible, describe the steps needed to re-create the problem. (e.g. "Just edit any checklist and click the green submit button.")

Of course, you could always write a checklist! (Have a play here: http://checklisthq.com)

Alternatively, buddy up with a dev or designer, watch what they're doing and sagely suggest things. :-)