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

Open up LSST software mailing lists

    Details

    • Type: Story
    • Status: Done
    • Resolution: Done
    • Fix Version/s: None
    • Component/s: SAT, TCT
    • Labels:
    • Story Points:
      1
    • Sprint:
      DevOps Sprint 1, DevOps Sprint 2
    • Team:
      SQuaRE

      Description

      We all benefit from making LSST software development as open as possible and conducive to outside volunteer contributions . One way to increase community involvement is to open up our development mailing lists to the public, analogous to the way other open source projects do. For example, we could have:

      • software-devel@lsstcorp.org: the development mailing list, equivalent to current lsst-data
      • software-users@lsstcorp.org: the users mailing list, equivalent to current lsst-dm-stack-users mailing list (but it could possibly be replaced by StackOverflow/Confluence Questions)
      • lsst-dm@lsstcorp.org: internal, DM-staff only mailing list, for the rare discussions/notices that should go out to staff only.

      Though we don't rely on them for meeting the project specs (legally required disclaimer ).

        Attachments

          Issue Links

            Activity

            Hide
            mjuric Mario Juric added a comment -

            It will make it easier to find things if we allow the archives to be indexed by Google

            Show
            mjuric Mario Juric added a comment - It will make it easier to find things if we allow the archives to be indexed by Google
            Hide
            ktl Kian-Tat Lim added a comment -

            I worry that forcing conversations to highly public lists will further diminish the willingness of people to start such conversations. An attitude of "I don't want to spam people with this" has already been expressed. As such, we need to make sure that there are "overflow" outlets for people to use; once a conversation has been started in a limited domain (e.g. HipChat or a team-only mailing list), we can move it to a more public one.

            Show
            ktl Kian-Tat Lim added a comment - I worry that forcing conversations to highly public lists will further diminish the willingness of people to start such conversations. An attitude of "I don't want to spam people with this" has already been expressed. As such, we need to make sure that there are "overflow" outlets for people to use; once a conversation has been started in a limited domain (e.g. HipChat or a team-only mailing list), we can move it to a more public one.
            Hide
            ktl Kian-Tat Lim added a comment -

            I think the discussion in Seattle converged on something like this:

            • dm-announce (LSST-paid people only)
            • dm-users (any stack user)
            • apps-devel (public)
            • mw-devel
            • qserv-l
            • infra-devel
            Show
            ktl Kian-Tat Lim added a comment - I think the discussion in Seattle converged on something like this: dm-announce (LSST-paid people only) dm-users (any stack user) apps-devel (public) mw-devel qserv-l infra-devel
            Hide
            frossie Frossie Economou added a comment -

            Pinging this ticket. If the watchers are happy it has iterated, please assign it to me to get it done.

            Show
            frossie Frossie Economou added a comment - Pinging this ticket. If the watchers are happy it has iterated, please assign it to me to get it done.
            Hide
            ktl Kian-Tat Lim added a comment -

            I don't think a consensus has been reached, and the implementation of lsst-dm-dev (ostensibly for buildbot results only, but now morphing into something else) has complicated things more.

            My opinions, for what they're worth:

            • People are now comfortable enough with alternate communication means that they can deal with public mailing lists.
            • Nevertheless, smaller mailing lists (fewer subscribers due to limited subject matter), perhaps in an aggregation hierarchy (e.g. posts to dm-devel get copied to apps-devel/mw-devel/qserv-l/infra-devel), will work better than larger ones.
            • qserv-l has already separated from lsstcorp.org; I'm a little worried this is undesirable.
            • We can only do things at a DM level for now, not at a project-wide level.
            • Rather than try to repurpose the hodgepodge we currently have, I'd rather blow it all up and do it rationally.
            Show
            ktl Kian-Tat Lim added a comment - I don't think a consensus has been reached, and the implementation of lsst-dm-dev (ostensibly for buildbot results only, but now morphing into something else) has complicated things more. My opinions, for what they're worth: People are now comfortable enough with alternate communication means that they can deal with public mailing lists. Nevertheless, smaller mailing lists (fewer subscribers due to limited subject matter), perhaps in an aggregation hierarchy (e.g. posts to dm-devel get copied to apps-devel/mw-devel/qserv-l/infra-devel), will work better than larger ones. qserv-l has already separated from lsstcorp.org; I'm a little worried this is undesirable. We can only do things at a DM level for now, not at a project-wide level. Rather than try to repurpose the hodgepodge we currently have, I'd rather blow it all up and do it rationally.
            Hide
            mjuric Mario Juric added a comment - - edited

            This ticket has lingered for too long (my fault). Let's put it on the SAT agenda for next week and make a recommendation. In the vein of Josh's little yellow meetings book, my proposal for the suite of public lists (based on Seattle discussion and some thinking afterwards) would be:

            • announce: a mailing list for public (e.g., release) announcements
            • devel: general development-related discussions (there will always be a need to reach all developers; e.g., the recent discussions on github-JIRA integration/notifications would go here)
            • pipelines-devel: discussions related to development of science pipelines (aka apps).
            • middleware-devel: lsst middleware development
            • qserv-devel: qserv development list

            I'd propose to have these in data.lsst.org domain (technology permitting), and have them w/o the (redundant) lsst- prefix (e.g., pipelines-devel@data.lsst.org, or announce@data.lsst.org).

            I'd propose to kill lsst-dm-stack-users in favor of Confluence Questions (or StackOverflow or AskBot – whatever SQuaRE recommends). Otherwise the discussion will bifurcate between the two.

            I'd propose to kill lsst-dm-dev in favor of buildbot sending notices to HipChat, both a buildbot room, and to Data Management room.

            I'd propose to have a private staff@data.lsstcorp.org mailing list, for broadcasts to DM staff only.

            K-T wrote:
            > Rather than try to repurpose the hodgepodge we currently have, I'd rather blow it all up and do it rationally.

            +1

            Show
            mjuric Mario Juric added a comment - - edited This ticket has lingered for too long (my fault). Let's put it on the SAT agenda for next week and make a recommendation. In the vein of Josh's little yellow meetings book, my proposal for the suite of public lists (based on Seattle discussion and some thinking afterwards) would be: announce: a mailing list for public (e.g., release) announcements devel: general development-related discussions (there will always be a need to reach all developers; e.g., the recent discussions on github-JIRA integration/notifications would go here) pipelines-devel: discussions related to development of science pipelines (aka apps). middleware-devel: lsst middleware development qserv-devel: qserv development list I'd propose to have these in data.lsst.org domain (technology permitting), and have them w/o the (redundant) lsst- prefix (e.g., pipelines-devel@data.lsst.org, or announce@data.lsst.org). I'd propose to kill lsst-dm-stack-users in favor of Confluence Questions (or StackOverflow or AskBot – whatever SQuaRE recommends). Otherwise the discussion will bifurcate between the two. I'd propose to kill lsst-dm-dev in favor of buildbot sending notices to HipChat, both a buildbot room, and to Data Management room. I'd propose to have a private staff@data.lsstcorp.org mailing list, for broadcasts to DM staff only. K-T wrote: > Rather than try to repurpose the hodgepodge we currently have, I'd rather blow it all up and do it rationally. +1
            Hide
            mjuric Mario Juric added a comment -

            Frossie Economou, Joshua Hoblitt and I had some further discussion today and converged to the following proposal (very similar to the one above):

            • data-announce@lsst.org: a mailing list for public (e.g., release) announcements
            • data-users@lsst.org: the list for users of DM software (it was felt that eschewing a mailing list for SO or CQ may be too radical)
            • data-devel@lsst.org: general development-related discussions (there will always be a need to reach all developers; e.g., the recent discussions on github-JIRA integration/notifications would go here)

            An alternative prefix may be 'dm-', if there's pushback that 'data-' is too broad. Another option (that just occurred to me and isn't necessarily supported by either Frossie or Josh) is 'code-'. All these lists would be public, archived, and open to anyone to subscribe.

            In addition to these, we would let any of the working groups (or subgroups) open mailing lists as necessary. So, for example, we could have algo-devel@lsst.org (for apps), or even diffim-devel@lsst.org (if algo-devel becomes unwieldy and needs further splitting), etc. We'll rely on common sense to not let the number of lists grow to >= number of people in DM. These lists could be private, if necessary, but the default should be to make them public.

            Finally there'd be a (private) dm-staff@lsstcorp.org, for broadcasts to DM staff only.

            Transition plan:

            We'd ask Iain to create these lists.

            Once they are created, the proposal is to retire and archive lsst-data and lsst-dm-stack-users lists after some grace period (~1 week).

            The subscribers to lsst-data would be alerted to re-subscribe to either the -announce, -users, or -devel lists. The subscribers to lsst-dm-stack-users will be alerted to the name change, re-subscribed to data-users (or, if Mailman allows for that, lsst-dm-stack-users would just be renamed to data-users), and an alias will be set up to forward e-mails from lsst-dm-stack-users to data-users.

            Show
            mjuric Mario Juric added a comment - Frossie Economou , Joshua Hoblitt and I had some further discussion today and converged to the following proposal (very similar to the one above): data-announce@lsst.org: a mailing list for public (e.g., release) announcements data-users@lsst.org: the list for users of DM software (it was felt that eschewing a mailing list for SO or CQ may be too radical) data-devel@lsst.org: general development-related discussions (there will always be a need to reach all developers; e.g., the recent discussions on github-JIRA integration/notifications would go here) An alternative prefix may be 'dm-', if there's pushback that 'data-' is too broad. Another option (that just occurred to me and isn't necessarily supported by either Frossie or Josh) is 'code-'. All these lists would be public, archived, and open to anyone to subscribe. In addition to these, we would let any of the working groups (or subgroups) open mailing lists as necessary. So, for example, we could have algo-devel@lsst.org (for apps), or even diffim-devel@lsst.org (if algo-devel becomes unwieldy and needs further splitting), etc. We'll rely on common sense to not let the number of lists grow to >= number of people in DM. These lists could be private, if necessary, but the default should be to make them public. Finally there'd be a (private) dm-staff@lsstcorp.org, for broadcasts to DM staff only. Transition plan: We'd ask Iain to create these lists. Once they are created, the proposal is to retire and archive lsst-data and lsst-dm-stack-users lists after some grace period (~1 week). The subscribers to lsst-data would be alerted to re-subscribe to either the -announce, -users, or -devel lists. The subscribers to lsst-dm-stack-users will be alerted to the name change, re-subscribed to data-users (or, if Mailman allows for that, lsst-dm-stack-users would just be renamed to data-users), and an alias will be set up to forward e-mails from lsst-dm-stack-users to data-users.
            Hide
            ktl Kian-Tat Lim added a comment -

            data-users doesn't really say software to me, and code-users seems way too broad: it would seem to include Camera/T&S/Sims/etc. So I prefer dm-, but could be persuaded to data-. Otherwise sounds good, including the transition plan.

            Show
            ktl Kian-Tat Lim added a comment - data-users doesn't really say software to me, and code-users seems way too broad: it would seem to include Camera/T&S/Sims/etc. So I prefer dm-, but could be persuaded to data-. Otherwise sounds good, including the transition plan.
            Hide
            ktl Kian-Tat Lim added a comment -

            The SAT recommended at its meeting on 2014-09-21 that Mario's proposal for data-announce, data-users, and data-devel be adopted. In addition, the SAT recommends that smaller groups be encouraged to set up their own mailing lists, ideally via self-service at lsst.org.

            Show
            ktl Kian-Tat Lim added a comment - The SAT recommended at its meeting on 2014-09-21 that Mario's proposal for data-announce, data-users, and data-devel be adopted. In addition, the SAT recommends that smaller groups be encouraged to set up their own mailing lists, ideally via self-service at lsst.org.
            Hide
            frossie Frossie Economou added a comment -

            Okay I suggest the TCT votes on this in a "confluence meeting" so it can go up to "Jario" for approval.

            Show
            frossie Frossie Economou added a comment - Okay I suggest the TCT votes on this in a "confluence meeting" so it can go up to "Jario" for approval.
            Hide
            frossie Frossie Economou added a comment -

            Robyn, I believe this is the right process, right? So please organise the TCT Confluence proposal/vote/thingie.

            Show
            frossie Frossie Economou added a comment - Robyn, I believe this is the right process, right? So please organise the TCT Confluence proposal/vote/thingie.
            Hide
            robyn Robyn Allsman [X] (Inactive) added a comment -

            Yes, I will setup the online TCT meeting on this proposal.

            Show
            robyn Robyn Allsman [X] (Inactive) added a comment - Yes, I will setup the online TCT meeting on this proposal.
            Hide
            robyn Robyn Allsman [X] (Inactive) added a comment -

            The TCT met on-line and voted 7 out of 7 respondents voted to allow the mail list change. 4 out of those 7 preferred to the prefix 'dm-' to 'data-'. There were 4 no-show TCT members.

            Show
            robyn Robyn Allsman [X] (Inactive) added a comment - The TCT met on-line and voted 7 out of 7 respondents voted to allow the mail list change. 4 out of those 7 preferred to the prefix 'dm-' to 'data-'. There were 4 no-show TCT members.
            Hide
            robyn Robyn Allsman [X] (Inactive) added a comment -

            Jeff responded in email on 28 Oct 2014:
            "Since it is Mario’s proposal I presume he votes yes, and I defer to his judgement."

            so this recommendation has been accepted by DM Management.

            Show
            robyn Robyn Allsman [X] (Inactive) added a comment - Jeff responded in email on 28 Oct 2014: "Since it is Mario’s proposal I presume he votes yes, and I defer to his judgement." so this recommendation has been accepted by DM Management.
            Hide
            robyn Robyn Allsman [X] (Inactive) added a comment -

            Oops. Workflow should have been Review Complete. When the lists are updated, it will move to Done.

            Show
            robyn Robyn Allsman [X] (Inactive) added a comment - Oops. Workflow should have been Review Complete. When the lists are updated, it will move to Done.
            Hide
            robyn Robyn Allsman [X] (Inactive) added a comment -

            The new mail-lists: dm-users, dm-devel, dm-announce, have been operational for > a month. If other new mail lists are required, open another Issue.

            Show
            robyn Robyn Allsman [X] (Inactive) added a comment - The new mail-lists: dm-users, dm-devel, dm-announce, have been operational for > a month. If other new mail lists are required, open another Issue.

              People

              • Assignee:
                mjuric Mario Juric
                Reporter:
                mjuric Mario Juric
                Reviewers:
                Jeff Kantor, Mario Juric, Robyn Allsman [X] (Inactive)
                Watchers:
                Frossie Economou, Jeff Kantor, Kian-Tat Lim, Mario Juric
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Summary Panel