Leaving process

From GEANT2-JRA1 Wiki

The process to be used when a particpant leaves the project is described below.

Image:Departure_process.jpg

Contents

[edit]

Notification

Notify the AL about departures as soon as possible (3 months in advance).

[edit]

Roles and product list

Roles and products within JRA1, SA3 WI-15 and perfSONAR.

  • Roles: the departing member has to list his roles (coordinate functional testing of xxx, administer knowledge base, etc) in the section 2 of the template.
  • Products: his/her tools he/she is working on (scripts, web-services, visualisations, documents, etc) in the section 4 of the above mentioned template.
  • The AL has to review the list with the relevant WILs and identify with the leaving member the priority and impact.

The objectives is to have a list of tools/activities that needs to be transitioned to somebody else. This implies documenting the process and tutoring the new people coming into the picture.

[edit]

Replacement?

Has the NREN has a replacement?

[edit]

Ressources Investigations

In the event where a NREN doesn't have a replacement

  1. What is their plan? - Identify when the NREN can get a replacement.
    1. If not possible, evaluate the time under which the products can stay without further progresses. This time minus one month (for getting up to speed) is the time that the NREN has to identify a replacement.
  2. Identify with the leaving participant whom could take over some actions (redistribution of responsibilities).
  3. Prioritise the work of the leaving member (documentation - release - mentoring)
[edit]

Product in the perfSONAR SVN

  • Must: Place the product (latest working code or document) in the SVN. Provide a change log and a pointer to the repository where the product code history is located (+ repository contact detail).
  • Nice to have: the code history
[edit]

Documentation

[edit]

Role documentation

  • Document the different roles the leaving member has. Each role should be seen as a tasks (processes with inputs, outputs, inter-actions with people, list or actions).
  • Please use one document per role. Please use template for documenting the roles (and the different tasks). Upload the document and link it from the document column of the the Status section. Notify the AL and WIL when a role is filled.
  • Examples or roles: RRD MA developer, SA3-WI15 leader, functional test coordinator, release manager, functional test scripts developer, editor, activity leader, etc. In the event there are some tasks you don't know which roles it relates, please indicate them in a separate document using the template document.
[edit]

Code Documentation

  • Code map: document aiming at enabling another developer to get started and understand the code. It includes (if those information were already provided e.g. in the code, please indicate it).
    1. what are the important source files, what are they used for, what are the important functions/methods and what are they used for.
    2. the list of knowledge (skills) required to take over the developments
    3. the list of tools and libraries relied upon (plus pointers)
    4. a known bug list, a todo list, and a list of long term ideas (preferably filed in bugzilla)
    • Must for: Web-service, visualisation, test scripts, scripts
  • Code comments
    • Nice to have for: Web-service, visualisation, test scripts, scripts
[edit]

Software Design documentation

  • Interface specifications - How to inter-act with the web-services
    • Must : for Web-service, follow .doc
  • Functional specifications (Include tool pupose)
    • Must: for Web-service, follow .doc
    • Must : for test scripts - template pointer to be sent by Michalis
    • Must for : Visualisation, scripts - no template prescribed.
[edit]

Installation, usage and configuration guide

  • Installation guide
    • Must for : Visualisation, test scripts, scripts
    • Must : for Web-service, follow .doc
  • Configuration guide
    • Must for visualisation, test scripts, scripts.
    • Must: for Web-serivce, follow .doc
  • User guide
    • Must for: Web-service, visualisation, test scripts, scripts
[edit]

Other

  • Contact information for further query
  • Nice to have: User list
    • List of users that are providing valuable feedback (name and email address).


[edit]

New participant taking over

  1. Introduce the new developer to the activity, send the developer welcome pack, define priority action plan.
  2. Disabling Accounts of the leaving participant - Pointer to newcoming process (to be done) to remove his/her accounts.
    • mailing list: jra1, ps-dev, perfsonar-support
    • Accounts: gn2-intranet, gn2 wiki, perfsonar wiki, GIdP
[edit]

Status

Leaving Tool and Role Replacement Ressouce Investigation Knowledge Transfer Documentation Code on SVN Check
UJ TC MP No Possible replacement in summer N/A Partial Yes NS


UJ TCMP-UI No Possible replacement in summer. Note, most of teh development were done by a colleague from UJ. N/A Partial Yes NS
LK SA3 WI-15 leadership (release coordination, web-admin, build) Not started 35% of tasks shifted to somebody else Started On-going
MM Web Admin,Testing Not Started Not Started Not started On going
  • Leaving: name of the person leaving
  • Tool and Role: tool name and role name
  • Replacement: Yes for replacement identified, No for replacement no identified
  • Ressouces Investigations: Note about them
  • Knowledge Transfer: Started, not started, contingency.
  • Documentation: Yes : available, No, not available, partial: partially available
  • Code on SVN: Yes, No
  • Verification : done by
Retrieved from "http://wiki.perfsonar.net/jra1-wiki/index.php/Leaving_process"
Personal tools