Difference between revisions of "FGdb goals for year end 2005"
Stillflame (talk | contribs) (added nice to have item) |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 6: | Line 6: | ||
# A meta-data script that produce usable meta-data for development, testing, and production. | # A meta-data script that produce usable meta-data for development, testing, and production. | ||
# The ability to track wholesale sales that are paid for in the store. (A wholesale checkbox on the receipt generation page, and the word "WHOLESALE" somewhere on the receipt.) | # The ability to track wholesale sales that are paid for in the store. (A wholesale checkbox on the receipt generation page, and the word "WHOLESALE" somewhere on the receipt.) | ||
| + | # test data that is usable with the actual database schema | ||
== Priority 2. Really nice to have, but can live without for now == | == Priority 2. Really nice to have, but can live without for now == | ||
| Line 11: | Line 12: | ||
# Data validation (probably including a drop down widget) for items sold in the store. | # Data validation (probably including a drop down widget) for items sold in the store. | ||
# Schema scripts that aren't maintained by hand. | # Schema scripts that aren't maintained by hand. | ||
| + | # programmatic way of getting anonymized test data from the production database | ||
| + | # Debian packaging and automatic package building | ||
== Priority 3. If possible == | == Priority 3. If possible == | ||
Latest revision as of 13:15, 29 November 2005
FGdb is Free Geek's database. The code base has changed significantly since the last time the development code was actually put into production. Meanwhile, there are certain features that Free Geek needs in order to track various sorts of income it depends upon. These features exist in the development code base, but have not yet been deployed to production. This proposal is a stab at guaranteeing that we will be able to use these features when the new year begins.
Priority 1. Must have
- The ability to deploy the development code into testing and production, see it work (or fail), and roll it back in case of failure.
- Schema scripts that produce identical database structures for development, testing, and production. (These could be kept in sync by hand if necessary.)
- A meta-data script that produce usable meta-data for development, testing, and production.
- The ability to track wholesale sales that are paid for in the store. (A wholesale checkbox on the receipt generation page, and the word "WHOLESALE" somewhere on the receipt.)
- test data that is usable with the actual database schema
Priority 2. Really nice to have, but can live without for now
- The income report breaks out wholesale sales from retail sales.
- Data validation (probably including a drop down widget) for items sold in the store.
- Schema scripts that aren't maintained by hand.
- programmatic way of getting anonymized test data from the production database
- Debian packaging and automatic package building
Priority 3. If possible
- Data validation (probably including a drop down widget) for items received.
- A sales report that drills down to a printable receipt (similar to what we have for donations).
- A unified receipt for donations, so that the one we produce and the one that is drilled down to from the donations report look the same.
Some of the above is started, finished, or trivial to get working, but there is a bottleneck when it comes to the ability to deploy the code.
The ability to analyze sales by type of item sold and wholesale vs. retail will be essential in figuring out how to make Free Geek cash flow positive.