New SoW

[bruskiza]

• Attempt at SoW in Markdown

[pippayeats]

MINI SCOPE OF WORK

Articles Category on TuneMe

BACKGROUND

The TuneMe mobisite, built using the Molo toolset, has three content categories: Your Body, Sex and Relationships. This SOW details the development of a fourth category: Articles. This category will be used for articles that are topical or do not fit in the other categories.

HOW WILL THIS PROJECT WORK?

An additional category will be added to the TuneMe mobisite.

1. This category will be called: Articles.
2. This new category will have the same features and functionality as the other categories.
3. This category will show in the Menu, above Your Body (at the top of the Menu).
4. This category will not show on the homepage.

Github issue	Estimated effort
[Link goes here]	X hours

CATEGORY DESIGN

1. The category will need the following to be designed:
2. A category color
3. A category icon
4. A set of icons for articles in this category

ASSUMPTIONS

• Designs will need to be completed and provided to the Solutions team prior to start of development.
• Each issue will be tracked in GitHub under their respective issues and will lead towards a milestone.
• Deadlines and delivery dates can only be confirmed once deposit is made and estimated efforts are not a guarantee of scheduled delivery.

[pippayeats]

@bruskiza Look it did it :) he he

[bruskiza]

@pippayeats yay! so, i take it a step further and actually put this in git directly...

Because each update to files in git are tracked atomically. Each update is recorded and kept track of.

• what time this was
• who did it
• what changes

Super pedantic I know but with multiple people having the potential to update things, it keeps us sane.

It also has the following benefits in my view:

• developers are watching commits to code all the time
• this is just another commit to them and they WILL ACTIVELY REVIEW IT, as it's part of their normal process
• changes in the comments above are not tracked, I changed "colour" to "color" as an example and there's no history that i can see of it being changed.

It also helps us manage scope creep because once the SoW is merged into the development branch, that fact is recorded and can be never forgotten. The SoW _CAN_ change but it would be another commit which can be tracked. And that would be a deviation from scope, which we will be in a better position to manage and deal with.

I have taken your markdown and put it in the docs/ folder here:

https://github.com/praekelt/molo-ndoh-yep/blob/feature/issue-78-pippa-sow-update/docs/2015-09-11-Articles-Scope-of-work.md

I can see there is duplication now as the google doc also references the same... but I like your style running this in parallel whilst we figure it out.

I'm encouraged to see where this takes us!

Please let me know if you have any other ideas, thoughts or concerns.

[bruskiza]

Also I can assist updating git and helping branching and merging.

[pippayeats]

Thanks @bruskiza ... yes running this in parallel to the normal process so I don't freak anyone out while we play around. But also trying to figure out what we present to clients and whether or not we have them view stuff on Git. I'm not sure if that is a good idea. But I also don't want two separate documents because trying to track changes on two is going to be a nightmare. Will keep thinking....

[bruskiza]

So because Markdown is structured data, lots of options:

http://www.markdowntopdf.com/

It creates a PDF that looks like this:

That's just one of many options. We could write our own Markdown to PDF writer that would include PRK logo's fonts etc.

And in that way: we still mail PDF's to clients as normal and not "scare" them with Git-related bits.

Also:

• Markdown plain text
• Limited formatting options = consistent look and feel, formatting etc.
• We could actually write TESTS for our documents to ensure they adhere to a common structure and have certain things... O_o. (baby steps bruce!)

But yes, a lot of possibilities.