From wiki.gpii
Revision as of 18:15, 16 December 2015 by X02069pheal (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

For each solution to be integrated the following steps will be performed by the Tiger Team:

  1. Identify key contact person(s) and contact them.
    1. Permissions - ownership - mgmt etc
    2. Technical (launch - settings access - meaning of settings)
  2. Redesign the way a product handles settings (optional)
    1. Saves preferences to better match the GPII
    2. Uses settings -- to allow live use of externally changed settings
  3. Create a translation/un-packing tool (as required)
    1. to convert binary and other compressed settings files into GPII inferrable/adjustable/transformable form.
  4. Register and align the preferences/settings in the product with the Preference Terms Definitions Registry
    1. mfgr might do -- but we should offer since MUCH MUCH easier for us to do because we know what is in Registry and what they are called
    2. mfgr should participate because they know what their terms mean
    3. ​Getting all the rest of their settings onboarded
      • get a list of their settings
      • find their counterpart in the Preference Terms Dictionary
        • if found  (with SAME definitions and SAME valuespace)
          • register them as an alias -- an note the commonFormat term
        • if not found (AND it is a term that might be used by others)
          • Create a commonFormat term
          • register their term as an alias
        • If NOT found and very low or no possible use to other apps as one of their settings (with same definition and value space
          • Then just enter as a new term using their format  
          • <FOR NOW just mark it on their list and don't enter it yet> 
  5. Launch and Setting handlers
    1. Create/adapt/select
    2. Can we do “live” settings change for context etc?
  6. Document
    1. Solution specific notes
    2. Generic documentation for others

Making code changes

We have a ticket for the solution being worked on and when ready will create a pull request against the universal repository on GitHub. For example

Code style

We should all be familiar with the Technical Standards and code conventions

In particular when making code contributions we should follow the coding conventions and running "grunt lint" to check code quality. The code styles are are those from the Fluid project which in turn are based on Crockford's.

Acceptance tests required for merge into master

While it is fine to raises a pull request to get comments and feedback if we want the code to be checked into maser them we need acceptance test. Thus we need to provide these for the solutions we add.

Acceptance tests simply check that the solution settings are correctly modified, the solution runs and uses the settings and when the solution is exited that the settings are restored.