Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-4658

Port code of conduct to new docs

    XMLWordPrintable

Details

    Attachments

      Issue Links

        Activity

          This is a quick review to tell you that the Code of Conduct doc is in sphinx docs now; no content changes.

          http://docs.lsst.codes/en/tickets-dm-4658/development/code_of_conduct.html

          jsick Jonathan Sick added a comment - This is a quick review to tell you that the Code of Conduct doc is in sphinx docs now; no content changes. http://docs.lsst.codes/en/tickets-dm-4658/development/code_of_conduct.html
          ktl Kian-Tat Lim added a comment -

          I'm fine with the content but, as indicated in the PR, I am a bit disturbed by the location of this document in both GitHub and docs.lsst.codes/development (or at least the overall title of "The LSST Science Pipelines" that has been given to the latter). Actually, something else – I think the implication is that docs.lsst.codes is updated/tagged per-release. That is not the case for these policies, which change on a different cadence. And it's not clear that having a historical record of the policies – except for coding standards – in force at the time of a particular release is relevant or useful.

          ktl Kian-Tat Lim added a comment - I'm fine with the content but, as indicated in the PR, I am a bit disturbed by the location of this document in both GitHub and docs.lsst.codes/development (or at least the overall title of "The LSST Science Pipelines" that has been given to the latter). Actually, something else – I think the implication is that docs.lsst.codes is updated/tagged per-release . That is not the case for these policies, which change on a different cadence. And it's not clear that having a historical record of the policies – except for coding standards – in force at the time of a particular release is relevant or useful.
          ktl Kian-Tat Lim added a comment -

          Not yet ready to merge until location questions are resolved.

          ktl Kian-Tat Lim added a comment - Not yet ready to merge until location questions are resolved.
          jsick Jonathan Sick added a comment - - edited

          Okay, we’ll hold off on merging DM-4412, DM-4658, DM-4657 until I come up with a cohesive documentation site architecture that accommodates the needs of documentation for individual software projects, docs for developer processes that apply across many DM products, and documentation for official policies that leadership approves (or possibly through an RFD/RFC?).

          The intent of these tickets was to take stock of what existed in Confluence, invest the effort into porting it into Git/reStructuredText now, and then sort out content architectures once the content was in a usable state. Keep in mind that lsst_stack_docs in lsst-sqre is not been announced as an official doc yet.

          jsick Jonathan Sick added a comment - - edited Okay, we’ll hold off on merging DM-4412 , DM-4658 , DM-4657 until I come up with a cohesive documentation site architecture that accommodates the needs of documentation for individual software projects, docs for developer processes that apply across many DM products, and documentation for official policies that leadership approves (or possibly through an RFD/RFC?). The intent of these tickets was to take stock of what existed in Confluence, invest the effort into porting it into Git/reStructuredText now, and then sort out content architectures once the content was in a usable state. Keep in mind that lsst_stack_docs in lsst-sqre is not been announced as an official doc yet.

          I didn't realize; if you're doing this as an "unofficial" work in progress, then it's fine to merge after the relatively minor content issues are resolved (none for this ticket).

          Are there stories for the more cohesive architecture yet?

          (And, yes, policies can be modified via RFC but require explicit approval of the TCT beyond just Assignee closure.)

          ktl Kian-Tat Lim added a comment - I didn't realize; if you're doing this as an "unofficial" work in progress, then it's fine to merge after the relatively minor content issues are resolved (none for this ticket). Are there stories for the more cohesive architecture yet? (And, yes, policies can be modified via RFC but require explicit approval of the TCT beyond just Assignee closure.)

          People

            jsick Jonathan Sick
            jsick Jonathan Sick
            Kian-Tat Lim
            Jonathan Sick, Kian-Tat Lim
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Jenkins

                No builds found.