As we discuss the housekeeping rules (in a separate thread), let's also discuss the actual project scope on this thread. Very few project ideas survive in their original form, most go thro' an iterative refinement. The strength of an idea isn't in its immutability ("unchangeable-ness"), but rather in its ability to act as a good seed for the n-th generation ideas that actually get implemented.
From some of the responses to my earlier proposal for this project (originally an idea from my brother), quite a few other people had similar ideas. Let's decide which aspects of the various projects get implemented, why they should be implemented, and in what version(s).
I'll start by outlining my ideas and reasons; please add your ideas and let's come to a rough consensus fairly quickly. Feel free as well to constructively critique other people's ideas. This stage should act as a filter to isolate unworkable ideas, or ideas that really should be a separate project altogether. Ok, here we go: - find out the cheapest petrol prices closest to you - report/update the prices of a petrol station - to simplify the project: - restrict the petrol stations only to Nairobi (for version 1) - the only interface will be SMS (subsequent versions may include other interfaces: web, mobile apps, etc etc) - pros: no one needs a smartphone, or data plan for this. Most ppl are already comfortable with SMSes. - cons: a lot of really snazzy, graphical features need a browser (or a capable smart/phone). But subsequent versions can include more advanced interfaces for phones that can support it. - use twitter's already-existing interface to receive and send SMSes. - pros: free, many good libraries exist, easy to quickly get started - cons: how many ppl in Nairobi use, or know about, twitter? How easy is it to quickly get a user sending/receiving messages on twitter via their phone? - to include as many people as possible: - use SMS as the main interface - allow a very fluid submission/query syntax (e.g. allow SMS-isms, abbreviations, incorrect street names etc etc There is a tension between making life simpler for the end-users (e.g. a forgiving language parser) and making life harder for the developers. It is easier, from a programming perspective, to only allow strict grammar in the SMSes sent, but that will likely make the application unusable for most people (imagine trying to query/submit petrol prices while driving, in perfect grammar!). Whenever possible, I tend to prefer transferring complexity away from the end-user and towards the programmer. These are some of the trade-offs we will have to decide on. Over to the community for a constructive back-and-forth... Saidi