https://pfspipe.ipmu.jp/jira This file is an XML representation of an issue en-us 8.3.4 803005 13-09-2019 https://pfspipe.ipmu.jp/jira/browse/INFRA-211 Software Development Infrastructure <ul> <li>Long name of a new project: PFS Documentation</li> <li>key (e.g. INFRA) of a new project: Doc</li> <li>username of project lead: hassan</li> <li>description: Track general activities related to documentation. Such documentation can address functions that span multiple JIRA projects. Example: the creation of a test plan for SM1 testing.</li> <li>Initial components: none</li> </ul> INFRA-211

Request for a new JIRA Project for general documentation tracking

Task Normal Open Unresolved yuki.moritani hassan Wed, 18 Jul 2018 15:46:03 +0000 Thu, 4 Apr 2019 15:28:24 +0000 0 1 <p>Note: there is an overlap with INFRA/ics-doc activities, but this appears to be the only one.</p> <p>Also note: an alternative of creating components for existing projects is not feasible, as activities such as tracking SM1-specific documentation can span more than one existing project.</p> <p>Note: this is just to make things clear.<br/> Is this project "planned" to cover all area of PFS software development, meaning all of DRP/ICS/SPT/etc. in the sole place...?<br/> Example seems not well reasoned or described, if SM1-specific means documentation for ICS/SM1 (or its operation) these are still within the ICS project which shall remain to the end of PFS.</p> <p>Yes, this is intended to cover all areas of PFS software development, with the exception of the documentation already available in the ics_doc repo, for which a JIRA INFRA component has already been defined.</p> <p>The SM1 example here was mentioned as activities up to SM1 acceptance already span multiple projects (PIPE2D, SIM2D as well as INSTRM). But I am happy to raise tickets on the INSTRM project, component=ics_doc if this is correct. </p> <p>My worry is that we will be writing PFS documentation that does not alway suit being placed in INSTRM/ics_doc. What do we do with these documents? Users would then have to waste valuable time contacting the jifa@pfs support to get help, or raise issues in the incorrect places. Raising issues should be as simple and as convenient as possible for the user, and having a single project to encompass all PFS documentation activities helps to active that.</p> Development Rank 0|s0005k: