Documentation: Code Management and Release Process

[mark]

Hi Jim and Chris (and Ed),

I'd like to start reviewing our docs on the Code Management and Release Process[fn1], and getting them up to date. I'm starting this ticket as a place I can ask questions. I've learned how to use both Features and Git in the last week, so although I know the BOA stuff still isn't quite stable, I reckon I could at least get started on the git/Features stuff.

So - questions for starters:

When we've got BOA working in anger, will we still use git for managing Themes and Features?

And, if the answer to that is yes, how would a new theme designer (for example) get cracking? They'd create a development copy of the TN.org site somewhere, but would they need to shove any data into that in order to test their theme?

I'll leave it at that for now. Could do with quickish replies, if poss?

Thanks!
Mark.

[fn1] ​/trac/wiki/CodeManagementReleaseProcess

[ed]

Notes from documentation meet 190113:

Documentation meeting
19/02/13
Sheffield

Mark Nielsen
Ed Mitchell

Actions
~
Ed link Mark to Laura's project ticket for addition to projects section
Mark to work 4-8 hours per week minimum
Mark to work with Jim on Aegir process
Ed to kick butts to get Aegir process requirements (e.g. logins set up)

Progress
~

• Started - been going OK. Held up by Aegir move. But that's not been bad for Mark or Ed.
• £218 invoiced, £788 to go
• Mark has learnt about Features and Aegir in the meantime.
• Wiki page set up:

​https://tech.transitionnetwork.org/trac/wiki/TransitionNetworkWebsite

• General introduction good

Agreements
~

• Deadline: end of March
• Ed to check on progress every fortnight for times and progress
• Level of detail fine
• Target audience - someone who isn't a drupal dev - more like a themer, who may not have experience of views and code best practice
• Best to use specific examples of cases rather than try to specify everything
• Use the following structure for each 'section' (a) general information (Best practice, training links, explanations) (b) how used on site (with examples) (c) Best Practice (e.g. view titles, don't change names of things etc.)
• Explanations need to be clear enough to form a term of agreement for some quality assessment - i.e. we need to use these to make the quality expectations clear, and in bad cases, as the baseline below which people are removed from the work.

To do: Sections

• Views
• Panels
• Context
• Features

-- Including a comment about risk as discussed

• Aegir and publishing process (working with Jim)

Examples to use
~

• Ingredients: views in context/panels (?)
• Training: Panel page
• Initiatives directory: views (esp. 'initiatives_directory' view)
• Homepage (?)
• Stories homepage (?)

[ed]

Tickets to refer to for the projects part of the documentation:
​https://tech.transitionnetwork.org/trac/ticket/459
​https://tech.transitionnetwork.org/trac/ticket/458

[ed]

closing as it's done :)