We discussed requirements gathering & contributing.

Requirements Gathering

Stress that we are building Business Automation & Analysis Software. Our scope is not necessarily limited to "Order Management".

We could create wiki pages for "Systems We Have Now" & "Developer's Wishlist". Systems would be a general overview of all our current business processes & their relations. This could be created from pre-existing knowledge & information gleaned from Thursday meetings & smaller group discussion about specific business areas.

What do we need from people?

  • How do they interact with the Business?
  • End goals of their interactions(why do they do these things?)
  • Their relative places in the Big Picture(relations with other areas).
  • Specific improvements they desire.
  • Who is responsible for what?

What do we want out of a Thursday meeting?

  • Sketch a graph of all Business areas & the relations between each area.
  • Possible pathways that orders flow through the Business.
  • List of people & their area of responsibilities(so we can work on specifics in smaller groups).

Customers, Order, Products - The Holy Trinity

Each has a "pipeline" we need to analyze & optimize:
  • inputs/sources
  • processes(e.g. approving, printing, picking)
  • divergences/sidechains(e.g. backordered)
  • end-point/destination(shipped/refunded/canceled/packed)

2 Stages?

  1. Current Business Process Information Gathering & Analysis
  2. New Process Design, Review & Validation

Potential Workflow

A "process" could be something like approving orders, bulk adding catalog subscribers or viewing a report(or more abstractly, just gathering some kind of information).

  1. Discover a specific Business process from a meeting or group discussion.
  2. Add process to Wiki page.
  3. Create new feature for process on Bug Tracker
  4. Extract information about requirements from a Point Person.
  5. Write specifications and/or tests for the process.
  6. Get feedback on specs from Point Person
  7. Revise specs based on feedback
  8. Repeat feedback/revise cycle until Point Person signs-off on specs.
  9. Merge the specs into the source code.

Writing Tests Alongside Specs
While writing specs, we could also write the shell of behavior/integration tests. This would provide actual verification of specifications, instead of "promises" given This would by documentation.

At the Spec Writing stage, tests that verify the required behavior could be created, but left unfilled - no actual verification would be done against the code. During the Development stage, the tests would be filled with code that actually verifies the behavior.

Interfaceing with External Applications

We should also determine what additional applications are used, with the hope of automating interactions between us and them. Their interfaces should be defined abstractly to keep everything modular:

abstraction -> implementation
  • Order Source -> Local Harvest
  • Accounting System -> Acorn Accounting
  • Web Store -> Zen Cart


What are contributer's desired levels of involvement?

Who wants to help work on what?

Some general tasks:
  • research
  • requirements gathering
  • spec writing
  • testing, test writing
  • documentation
  • program design
  • ui design
  • development

Pavan: From everything to anything anyone else doesn't want to do, from beginning to forever.


How do people want to get changes merged in? We could give everyone the ability to merge into the main development branch of the source code, or we could do something like a single maintainer/merger while everyone else submit pull requests.

Pavan wants to inherit the development workflow from the Accounting App. A lot of this is documented:

The format of design specifications:
(flowcharts and stuff are on the PDF version: http://lists.sleepanarchy.com/archives/ordermanager-develop/attachments/20140929/83954364/attachment-0001.pdf)

Feedback on any of this is appreciated.