10-day plans

Day 1: Plan and write down what to do on paper and on the wiki page what to do over the next week discuss the same in the IRC channel. Day 2 to Day 8: Code, code, code, document (1 week) Day 9: Document, if the contents don't resemble "spam" (:P) send out an email detailing the changes made, problems being faced requesting comments. Day 10: Act upon feedback, finalize, make sure everything works, write tests wherever possible.

• First trimester: mock-ups and getting familiar.
  • Period: 1 May - 9th July (will be having exams till 30 April)
    • SMART Goal: Creation of wireframes for the GUI components. Revising project goals and methodologies with mentors. Familiarity with Agasti’s CAP implementation.
    • Measure: good mock-ups of the views as specified above in the GUI section of implementation details. A complete specification of the project.
  • Second trimester: Implementation of basic models and controllers to use and build on to make the mock-ups function. XML <-> Storage conversions.
    • Period: 22 May - 9 July
    • SMART Goal: Write required models and controllers to make creation, update and deletion of CAP elements: Profiles, Templates and Alerts.
    • Measure: A working implementation of CAP Broker, without the interop or the publisher-subscriber model.
    • Finer details (in 10 day chunks, see not above):
      • 22 May - 31 May: Get CAP Profiles working. Start with the required models, get it reviewed, create the UI, get it working, show it to gnewy. Come up with a format for exporting and importing these (will do this during community bonding), implement export / import.
      • 01 June - 10 June: CAP Templates -- Create M,V,C for this, in that order. Run it through devs. Export this using CAP XML. Implement Export import.
      • 11 June - 20 June: CAP Alerts editing -- Take 3-4 days to implement area representation on a map. Implement M, V, C, in that order. Run it through devs. Implementing export / import should be straight forward and take less than a day due to code created in the previous 10 days.
      • 21 June - 25 June: Review previously written code, document wherever left out, ask questions and address use cases, fix bugs.
      • 26 June - 5 July: Make the view for the map and the listing of alerts. At this point, provide actions to send out update and cancel with easy referencing of an alert.
      • 5 July - 9 July: Document anything left out. Write user documentation. run everything through the mailing list, prepare for mid-term evaluation.
  • Third Trimister: Implementing broadcast and inter-op features.
    • Period: 10 July - 13 August
    • SMART Goal: Implementing broadcasting of incoming alerts. Build an event-triggering system which can be hooked into to provide various broadcast media; use the s3msg framework for implementing broadcast. Implement a user interface, models and controllers for subscribing via these media: Twitter, SMS (will require implementing UI for setting up SMS gateways to work through / clickatell accounts for bulk sms), email and PuSH. Incorporate PuSH features to s3msg framework and use the event system to broadcast PuSH messages. Implement XSL and XSLT to transform CAP XML documents into text usable in the above media.
    • Measure: An alerting system which broadcasts to subscribers of the service. The subscriber can subscribe with broadcast media of the following types: twitter, SMS, email, WebService endpoint (a POST will be sent). XSL and XSLT documents to transform CAP messages into text for above media.
    • Finer details:
      • 10 July - 20 July: Make the UI, data model and controllers for registering user's contact information (look at ways of reusing existing S3 modules here on the first day, write it down and show flavour -- do this during community bonding). Here, admins should be allowed to set up Twitter accounts to update with alerts.
      • 21 July - 30 July: Implement any left-over work from the previous 10 days, then broadcasting via SMS, Twitter, Email. Write down XSL and XSLT files to transform XML Cap messages to output suitable for each broadcast service.
      • 31 July - 10 Aug: Implement POST endpoint and querying, Publish-Subscribe. Implement UI to register more other brokers which support Subscribe. (note: will need to make sure the URI's for alerts will prevent alerts from going in loops from broker 1 to broker 2 to broker 1 to broker 2)
      • 10 Aug - 20 Aug: Final review and rebasing of code. User documentation for code in third trimester.