Contents 1 General Project Goals 2 User Work Flow 2.1 Finding Edibles (Accessing Data) 2.2 Adding Edibles (Contributing Data) 3 Features 4 Software / Service Stack 5 Models 5.1 Wheres (Edibles / Locations) 5.2 Whats (Food types) 5.3 Whens (Seasonal data) 5.4 Whos (Users) 5.5 Hows (Educational data) 5.6 Flags 5.7 Comments 5.8 Models for Text/Other Content 6 Main Views 7 Tests 7.1 Writing Tests 7.2 Running Tests 7.2.1 Run all tests 7.2.2 Run tests for specific model 7.2.3 Run tests for specific model test suite 7.2.4 Run tests for specific model test

General Project Goals

off the cuff from Michael:

• Creating awareness
• Providing an open resource.
• Facilitating contact with nature and our neighbors
• NOT providing a service

User Work Flow

Finding Edibles (Accessing Data)

• what's near me?
• what can be picked now?
• what does it look like?
• how do I harvest it?
• what can I do with it? (cook, tincture, preserve)

Adding Edibles (Contributing Data)

• identify an edible
• record/add its location (paper -> computer or directly with mobile)
• share comments/rating on season status, abundance, accessibility, permissions
• share extra media about edible (Photo, others?)
• help keep edible up to date (annual email check ins?)
• learn about other edibles and methods
• share, organize, repeat

Features

See New Feature Ideas while a more formal list is generated here.

Software / Service Stack

• Language: Python
• Web Framework: Django
• Version Control: Mercurial on Google Code (http://code.google.com/p/urbanedibles/ - out-of-date)
• Mapping: GeoDjango & Google Maps API

• Javascript Library: jQuery or Rick's recommendation
• Database: PostgreSQL or App Engine
• more in notes...

Models

This is an informal brainstorm of the main database models

Wheres (Edibles / Locations)

• lat, long
• original street address?
• edible type (what_id)
• submitted by (user id, email, open_id?)
• permission type (submitted by owner, scout with permisson, scout without permission)
• some sort of rating rubric, or record of observations/quality over time
• timestamps

Whats (Food types)

• common name
• latin genus?
• edibility
• region (for associating with community group or seasonal data)
• photo(s)
• further data: (may be aggregated from another sources)
  • identification info
  • harvesting info
  • preparation
  • recipes
  • other resources / links

Whens (Seasonal data)

• Climate zone ID (from something like this)
• Season start
• Season end

Whos (Users)

Anonymous users can add or search but not remove or change edibles. Anonymous can flag sources for revision, removal, poisonous lookalike. Anonymous can add ratings or status to existing sources (ripe now, flowering, ...) Users can manage their own sources, avoid captcha, others?

• email
• password
• nickname?

Hows (Educational data)

• Type of Edible (foreign key to "What")
• Identification
• Harvesting
• Medicinal Uses
• Recipes
• Preservation (storing, fermentation, etc)

Flags

• type of flag (revision, removal, poisonous lookalike warning)
• location of edible (where_id)
• comment
• submitted by

Comments

• where_id
• body
• user_id or email

Models for Text/Other Content

• About page
• Ethics
• Resources (videos, links, etc)
• ...

Main Views

Search

• By street address
• By source type (plum)
• What's in season now
• "Come and get it"
• Printable map

Add Source

• Add multiple sources
• Submit by address or lat/long
• Auth with open ID to be able to edit your sources
• Confirm location of source with zoomed in map
• Auto-complete source category

Browse view can be replace with more comprehensible search page

Front page

• Urbanedibles.org includes world map that pulls in data from regional projects

Other Pages

• About
• Ethics (with comments?)
• Resources

Tests

Improve this area as we develop our tests...

Django Docs http://docs.djangoproject.com/en/dev/topics/testing/#topics-testing

Writing Tests

Unit tests -- tests that are expressed as methods on a Python class that subclasses unittest.TestCase.

Create test files called tests.py in the application directory -- i.e., the directory that holds models.py. The test runner looks for any subclass of unittest.TestCase in this module.

Running Tests

When you run your tests, the default behavior of the test utility is to find all the test cases (that is, subclasses of unittest.TestCase) in models.py and tests.py, automatically build a test suite out of those test cases, and run that suite.

There is a second way to define the test suite for a module: if you define a function called suite() in either models.py or tests.py, the Django test runner will use that function to construct the test suite for that module. This follows the suggested organization for unit tests. See the Python documentation for more details on how to construct a complex test suite.

For more details about unittest, see the standard library unittest documentation.

Run all tests

$ ./manage.py test

Run tests for specific model

$ ./manage.py test my_model

Run tests for specific model test suite

$ ./manage.py test my_model.MyTestCase

Run tests for specific model test

$ ./manage.py test my_model.MyTestCase.testMyCase