New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

High-volume discussion channel? volume@ list? #112

Open
wking opened this Issue May 6, 2016 · 25 comments

Comments

Projects
None yet
8 participants
@wking
Member

wking commented May 6, 2016

For a while now (maybe a year?), high-volume discuss@ threads have been moved to GitHub issues to avoid flooding inboxes for subscribers who don't have thread-muting capabilities. It's possible that the discuss@ list was initially intended to be high-volume, but currently it is not. Alternative high-volume locations include GitHub and Slack. I prefer email, because:

  • Issues I open on GitHub don't end up in my local email archives, since GitHub doesn't support “create an issue by email” (as far as I know).
  • Recent GitHub rendering for emailed comments don't show quoted text when replying inline.
  • It's hard to have deeper, asynchronous discussion on Slack. There is only so much thought you can pack into a line so posts summarizing previous discussion are difficult.
  • SWC Slack archives are private (I think?), so links from commit messages and stuff to “see Slack discussion {here}” aren't as useful.
  • There are open source, mail-archive-serving tools that can be used to host archives if/when lists.software-carpentry.org goes down. Anyone can host such an archive from their local email store. If/when GitHub and Slack go down, it's less obvious how to migrate the archives to another host.

I'd like to see a lists.software-carpentry.org list (volume@?) that is understood to be a “don't complain about the volume” list. Obviously, once ideas settled down there, folks could take them into discuss@ (or other appropriate channel). But it would make public space for the high-volume discussions that are currently happening in private or less-ideal channels.

@wking

This comment has been minimized.

Show comment
Hide comment
@wking

wking May 6, 2016

Member

A good model for my preferred approach is the Linux kernel, where just about everything CCs linux-kernel@ (would be our volume@) and there are other lower-volume lists for more targeted discussion. That way threads punted from a lower-volume list (discuss@?) would already be present in volume@ for continued discussion by folks who wanted to keep beating the dead horse discussing them ;).

Member

wking commented May 6, 2016

A good model for my preferred approach is the Linux kernel, where just about everything CCs linux-kernel@ (would be our volume@) and there are other lower-volume lists for more targeted discussion. That way threads punted from a lower-volume list (discuss@?) would already be present in volume@ for continued discussion by folks who wanted to keep beating the dead horse discussing them ;).

@ctb

This comment has been minimized.

Show comment
Hide comment
@ctb

ctb May 7, 2016

See also my comment #111 (comment).

Specifically,

"""
It would be good to articulate clearly and precisely the long-standing (but perhaps rarely specified) goal that this list is meant to be a low volume discuss list. I know @gvwilson (the creator of the list and founder of SCF) has struggled to maintain a balance between participation and deluge, and I know many, many people who have dropped off the list as the volume has grown. To try to articulate it myself, the discuss list is one of the primary information channels for what is going on with Software Carpentry and its associated community of instructors (which now includes Data Carpentry and others), and should be kept for information updates and requests for links, not for broad and opinionated discussion.

Maybe we should have some advice to lurk on the list a bit to see how things are done in this community and on this list? We punt threads to github a few times a month IIRC. I don't know if S.G. would have benefited from a few weeks reading the list before jumping into the fray (I recall her saying that she'd joined just a few days ago somewhere).

There could be an address or a FAQ to re list policies, and then a resolution address for people who are wondering what they are and why. The list is simply not the right place to discuss list policies IMO; see next point.
"""

ctb commented May 7, 2016

See also my comment #111 (comment).

Specifically,

"""
It would be good to articulate clearly and precisely the long-standing (but perhaps rarely specified) goal that this list is meant to be a low volume discuss list. I know @gvwilson (the creator of the list and founder of SCF) has struggled to maintain a balance between participation and deluge, and I know many, many people who have dropped off the list as the volume has grown. To try to articulate it myself, the discuss list is one of the primary information channels for what is going on with Software Carpentry and its associated community of instructors (which now includes Data Carpentry and others), and should be kept for information updates and requests for links, not for broad and opinionated discussion.

Maybe we should have some advice to lurk on the list a bit to see how things are done in this community and on this list? We punt threads to github a few times a month IIRC. I don't know if S.G. would have benefited from a few weeks reading the list before jumping into the fray (I recall her saying that she'd joined just a few days ago somewhere).

There could be an address or a FAQ to re list policies, and then a resolution address for people who are wondering what they are and why. The list is simply not the right place to discuss list policies IMO; see next point.
"""

@wking

This comment has been minimized.

Show comment
Hide comment
@wking

wking May 7, 2016

Member

On Fri, May 06, 2016 at 08:51:46PM -0700, C. Titus Brown wrote:

It would be good to articulate clearly and precisely the
long-standing (but perhaps rarely specified) goal that this list is
meant to be a low volume discuss list.

I'd recommend descriptions in 1 and 2 for that (and 2 already
has volume estimates, see swcarpentry/website#373). The rest of your
comment sounds good to me as well, but is maybe orthogonal to “where
should the high-volume discussion go?”, which is what I'm trying to
resolve here.

Member

wking commented May 7, 2016

On Fri, May 06, 2016 at 08:51:46PM -0700, C. Titus Brown wrote:

It would be good to articulate clearly and precisely the
long-standing (but perhaps rarely specified) goal that this list is
meant to be a low volume discuss list.

I'd recommend descriptions in 1 and 2 for that (and 2 already
has volume estimates, see swcarpentry/website#373). The rest of your
comment sounds good to me as well, but is maybe orthogonal to “where
should the high-volume discussion go?”, which is what I'm trying to
resolve here.

@swaldman3

This comment has been minimized.

Show comment
Hide comment
@swaldman3

swaldman3 May 7, 2016

Member
  • Personally I'd also prefer low- and high-volume mailing lists to other solutions. The convention on many projects is -announce and -discuss. However, I accept that may be in a minority.
  • The most important thing for me is that discussions remain in one place, and do not spread. At the moment, therefore, once a thread is moved to GitHub, it should not also be allowed to continue on the list.
  • One problem that I have with things being moved to GitHub as Issues is that they can be hard to find without a link. There are many repos in SWC, and it's not always clear to me which one a given discussion will be under. Perhaps there is a technical solution to this? (do all discussions that are not actually Issues re a particular repo go to Board? If so, maybe that just needs to be made obvious)
Member

swaldman3 commented May 7, 2016

  • Personally I'd also prefer low- and high-volume mailing lists to other solutions. The convention on many projects is -announce and -discuss. However, I accept that may be in a minority.
  • The most important thing for me is that discussions remain in one place, and do not spread. At the moment, therefore, once a thread is moved to GitHub, it should not also be allowed to continue on the list.
  • One problem that I have with things being moved to GitHub as Issues is that they can be hard to find without a link. There are many repos in SWC, and it's not always clear to me which one a given discussion will be under. Perhaps there is a technical solution to this? (do all discussions that are not actually Issues re a particular repo go to Board? If so, maybe that just needs to be made obvious)
@wking

This comment has been minimized.

Show comment
Hide comment
@wking

wking May 7, 2016

Member

On Sat, May 07, 2016 at 01:55:17AM -0700, Simon Waldman wrote:

  • Personally I'd also prefer low- and high-volume mailing lists to
    other solutions. The convention on many projects is -announce and
    -discuss.

A high-volume -discuss and a read-only (for most folks) -announce
doesn't leave a platform for folks looking for thoughtful,
reasonably-paced discussion ;). With the “always CC volume@”
approach, discussion can start on a low-volume list, and seamlessly
transition to the high-volume list if/when it gets too much traction.
Folks who have only subscribed to the low-volume list but replied to
the low-volume portion of the thread will be CCed by future reponses
that no longer CC the low-volume list (assuming we get everyone in the
habit of replying to all ;).

  • One problem that I have with things being moved to GitHub as
    Issues is that they can be hard to find without a link.

Solution to discovery is to have someone (ideally the thread mover)
post to the old channel with a link to the new discussion. That goes
for all “hey, I've found some related discussion” cases, and isn't
specific to discussion-migration.

Member

wking commented May 7, 2016

On Sat, May 07, 2016 at 01:55:17AM -0700, Simon Waldman wrote:

  • Personally I'd also prefer low- and high-volume mailing lists to
    other solutions. The convention on many projects is -announce and
    -discuss.

A high-volume -discuss and a read-only (for most folks) -announce
doesn't leave a platform for folks looking for thoughtful,
reasonably-paced discussion ;). With the “always CC volume@”
approach, discussion can start on a low-volume list, and seamlessly
transition to the high-volume list if/when it gets too much traction.
Folks who have only subscribed to the low-volume list but replied to
the low-volume portion of the thread will be CCed by future reponses
that no longer CC the low-volume list (assuming we get everyone in the
habit of replying to all ;).

  • One problem that I have with things being moved to GitHub as
    Issues is that they can be hard to find without a link.

Solution to discovery is to have someone (ideally the thread mover)
post to the old channel with a link to the new discussion. That goes
for all “hey, I've found some related discussion” cases, and isn't
specific to discussion-migration.

@jeremycg

This comment has been minimized.

Show comment
Hide comment
@jeremycg

jeremycg May 7, 2016

Member

Mailman supports enabling 'digests' of email lists.

Digest lists allow some users to receive all emails to the list in a day (or specified time/number of messages) condensed into one email, while other high volume users receive emails as they are sent by subscribing to the non-digested list. The downside is joining in on a thread if you are only subscribed to the digest is a little difficult.

It is currently enabled on discuss, but a little hard to find - I think the button on the sign up page saying 'Would you like to receive list mail batched in a daily digest?' Will sign you up for the digest rather than the full list.

We could change the default discuss list to be a digest (not sure if this is possible without forcing users to resubscribe), and enable those who want higher volume to subscribe to the 'full version'.

Member

jeremycg commented May 7, 2016

Mailman supports enabling 'digests' of email lists.

Digest lists allow some users to receive all emails to the list in a day (or specified time/number of messages) condensed into one email, while other high volume users receive emails as they are sent by subscribing to the non-digested list. The downside is joining in on a thread if you are only subscribed to the digest is a little difficult.

It is currently enabled on discuss, but a little hard to find - I think the button on the sign up page saying 'Would you like to receive list mail batched in a daily digest?' Will sign you up for the digest rather than the full list.

We could change the default discuss list to be a digest (not sure if this is possible without forcing users to resubscribe), and enable those who want higher volume to subscribe to the 'full version'.

@SpacedGirl

This comment has been minimized.

Show comment
Hide comment
@SpacedGirl

SpacedGirl May 7, 2016

Noticed that many people are very-pro email only dissemination of info and others very anti-high volume email.

Originally and generally am pro-email cause it makes more easier viewing for myself but was thinking about an alternative. Remember Greg's p.s. -->seems like something to that effect currently exists but I also figured out another possible solution for some of the pro-emailers.

What about a weekly announcement [like a digest though less data heavy....at least in terms of ones I've seen] that references all new github issues as well as active ones in the last week. Something as basic as mentioning the comment volume [# in the last week] would also be helpful for people wanting to check out or avoid any prolonged action.

SpacedGirl commented May 7, 2016

Noticed that many people are very-pro email only dissemination of info and others very anti-high volume email.

Originally and generally am pro-email cause it makes more easier viewing for myself but was thinking about an alternative. Remember Greg's p.s. -->seems like something to that effect currently exists but I also figured out another possible solution for some of the pro-emailers.

What about a weekly announcement [like a digest though less data heavy....at least in terms of ones I've seen] that references all new github issues as well as active ones in the last week. Something as basic as mentioning the comment volume [# in the last week] would also be helpful for people wanting to check out or avoid any prolonged action.

@wking

This comment has been minimized.

Show comment
Hide comment
@wking

wking May 8, 2016

Member

We should definitely be suggesting digests to folks that report
annoyance at list volume. But for folks who haven't tuned their mail
setup to handle high volume, I expect most will also not be familiar
enough with their MUA to reply to a specific messages that are
sub-parts of a multipart/digest 1. And while Mutt supports replying
to a specific sub-message, I'm not sure how widespread such support is
(even if users are intimately familiar with their MUA). Replying to
the digest (instead of a message sub-part) creates orphaned messages
like 2 which aren't attached to their parent thread. So I suspect
pushing digests is a useful but incomplete solution.

Manually curated summaries are lovely, and @anelda has done a lot of
good stuff here, e.g. [3,4,5,…]. But keeping that up with a frequency
and level of detail to help folks connect to active discussions is a
lot to ask.

 Subject: Re: [Discuss] Discuss Digest, Vol 27, Issue 15
 Date: Sun, 25 Oct 2015 09:09:48 -0700
 Message-ID: <CAMqtenSqWDyaiaW2K6YMvT-potxMs-AaNTJMdwB+gJxKKoqmWw@mail.gmail.com>
Member

wking commented May 8, 2016

We should definitely be suggesting digests to folks that report
annoyance at list volume. But for folks who haven't tuned their mail
setup to handle high volume, I expect most will also not be familiar
enough with their MUA to reply to a specific messages that are
sub-parts of a multipart/digest 1. And while Mutt supports replying
to a specific sub-message, I'm not sure how widespread such support is
(even if users are intimately familiar with their MUA). Replying to
the digest (instead of a message sub-part) creates orphaned messages
like 2 which aren't attached to their parent thread. So I suspect
pushing digests is a useful but incomplete solution.

Manually curated summaries are lovely, and @anelda has done a lot of
good stuff here, e.g. [3,4,5,…]. But keeping that up with a frequency
and level of detail to help folks connect to active discussions is a
lot to ask.

 Subject: Re: [Discuss] Discuss Digest, Vol 27, Issue 15
 Date: Sun, 25 Oct 2015 09:09:48 -0700
 Message-ID: <CAMqtenSqWDyaiaW2K6YMvT-potxMs-AaNTJMdwB+gJxKKoqmWw@mail.gmail.com>
@ctb

This comment has been minimized.

Show comment
Hide comment
@ctb

ctb May 8, 2016

I don't like the idea of fragmenting the community discuss list more. Also, decisions have a way of getting made on high volume lists, which I think is bad (since I can't keep up with high volume lists, but those decisions impact me - a common problem for the people in the SCF community who move into faculty positions, just for one).

An alternative approach would be to have a policy that essentially every post to discuss@ gets a github issue automatically created for it, and nobody replies on list. That way topics can be created on discuss, but moved immediately to github. That's functionally equivalent to just telling everyone to subscribe to a 'discuss' github forum, actually. So. hmm.

ctb commented May 8, 2016

I don't like the idea of fragmenting the community discuss list more. Also, decisions have a way of getting made on high volume lists, which I think is bad (since I can't keep up with high volume lists, but those decisions impact me - a common problem for the people in the SCF community who move into faculty positions, just for one).

An alternative approach would be to have a policy that essentially every post to discuss@ gets a github issue automatically created for it, and nobody replies on list. That way topics can be created on discuss, but moved immediately to github. That's functionally equivalent to just telling everyone to subscribe to a 'discuss' github forum, actually. So. hmm.

@anelda

This comment has been minimized.

Show comment
Hide comment
@anelda

anelda May 8, 2016

[apologies was logged in on another account and didn't realise I was posting under that account earlier - just reposting as myself]

HI @wking and all, thanks for including me in this conversation. I've been doing the "weekly" summary for some time now (although not the past month as I was really swamped). I love doing the weekly summary as it has really taught me so much about the community and the diverse activities - sometimes beyond running workshops.
I've recently appointed a training coordinator who will in time amongst other things help with the summaries, but I also know the SC (at least @jduckles and I think @rgaiacs) have been thinking of ways to automate them (summaries).
I typically try to include interesting conversations from the lists, tweets that didn't make it into the blogs, the blogs themselves, and then "independent" blogs or news articles on other people's sites (revealed by a "Software Carpentry" Google search).
I wonder if the weekly summary isn't maybe a good place for new instructors to start contributing? Maybe we could do a 52-week allocation for 1-3 people per week to collaboratively produce the weekly summary including what I've listed above. It will prompt people to read the blogs, discuss, etc and will help them contribute visibly to the community without having to dedicate too many hours or days? (for this I include @gvwilson on the conversation)
On another note, I would support splitting of the list into an "announce" and "discuss" list. I think the conversation over the last few days would scare the living daylights out of most of our newly trained instructors (who yet have to qualify).
I love the Software/Data Carpentry community for always finding solutions instead of sitting around and moan about what is wrong and that is how I advertise the community to everyone I encounter - "“It brings together researchers from all career stages and all disciplines around the world and not only facilitates an opportunity for this diverse community to communicate their challenges in research computation, publication and other related topics, but actually converts these conversations into actionable outputs.”[1] I trust we will find a solution to the last few days of intense discussion - several solutions actually - the list, the CoC, etc.
@wking I'm glad to hear the summaries have helped people :-)

Let me know how I can help?

[1] http://www.eresearch.uct.ac.za/news/software-carpentry-powerful-initiative

anelda commented May 8, 2016

[apologies was logged in on another account and didn't realise I was posting under that account earlier - just reposting as myself]

HI @wking and all, thanks for including me in this conversation. I've been doing the "weekly" summary for some time now (although not the past month as I was really swamped). I love doing the weekly summary as it has really taught me so much about the community and the diverse activities - sometimes beyond running workshops.
I've recently appointed a training coordinator who will in time amongst other things help with the summaries, but I also know the SC (at least @jduckles and I think @rgaiacs) have been thinking of ways to automate them (summaries).
I typically try to include interesting conversations from the lists, tweets that didn't make it into the blogs, the blogs themselves, and then "independent" blogs or news articles on other people's sites (revealed by a "Software Carpentry" Google search).
I wonder if the weekly summary isn't maybe a good place for new instructors to start contributing? Maybe we could do a 52-week allocation for 1-3 people per week to collaboratively produce the weekly summary including what I've listed above. It will prompt people to read the blogs, discuss, etc and will help them contribute visibly to the community without having to dedicate too many hours or days? (for this I include @gvwilson on the conversation)
On another note, I would support splitting of the list into an "announce" and "discuss" list. I think the conversation over the last few days would scare the living daylights out of most of our newly trained instructors (who yet have to qualify).
I love the Software/Data Carpentry community for always finding solutions instead of sitting around and moan about what is wrong and that is how I advertise the community to everyone I encounter - "“It brings together researchers from all career stages and all disciplines around the world and not only facilitates an opportunity for this diverse community to communicate their challenges in research computation, publication and other related topics, but actually converts these conversations into actionable outputs.”[1] I trust we will find a solution to the last few days of intense discussion - several solutions actually - the list, the CoC, etc.
@wking I'm glad to hear the summaries have helped people :-)

Let me know how I can help?

[1] http://www.eresearch.uct.ac.za/news/software-carpentry-powerful-initiative

@wking

This comment has been minimized.

Show comment
Hide comment
@wking

wking May 8, 2016

Member

On Sun, May 08, 2016 at 07:01:02AM -0700, C. Titus Brown wrote:

An alternative approach would be to have a policy that essentially
every post to discuss@ gets a github issue automatically created for
it, and nobody replies on list.

You've mentioned the “only post links” approach a few times, but it's
only just sunk in. Thanks for repeating yourself until I noticed what
you were saying :p. I like this approach, since it's easy to explain,
hard to botch, and easy to objectively identify violators (for links
to docs and then eventually bans for repeated violations). I think we
need consensus around where the linked channel should be. Most
discussions will result in a change to a swcarpentry repo, so linking
to a GitHub issue or pull request is probably the right thing to do
(even though I'd prefer email for the reasons listed in 1).

Also, decisions have a way of getting made on high volume lists,
which I think is bad…

I agree that the broader community should be kept abreast of any
decisions, ideally in time to chime in before they are officially
adopted. I'd recommend the usual approach be something like:

  1. Create swcarpentry/$REPO#$ISSUE (or a pull request, or whatever)
    outlining $IDEA.

  2. Post to the low-volume channel:

    Hi everyone,

    I've opened https://github.com/swcarpentry/$REPO/issues/$ISSUE to
    discuss $IDEA. Please join in if you're interested.

  3. Discussion happens in the issue from step 1, and eventually settles
    around a recommended $ACTION.

  4. Post a reply to the step-2 message with:

    We've reached a consensus and plan to take $ACTION on $DATE.
    Therefore if anyone can shew any just cause why this may not be a
    good idea, post to the GitHub issue now, or else hereafter for at
    least six months hold your peace [2].

  5. If new concerns are raised, go back to step 3.

  6. $DATE arrives without new concerns.

  7. $ACTION is taken.

Although in cases where the actor considers the likelyhood or risk of
disagreement small, you can skip straight from step 3 to 7. And for
really minor or serious issue, you can skip straight from step 1 to 7.
And there are probably many other tweaks that are appropriate in a
given situation, with the only important rule as far as volume and
discussion fragmentation are concerned is “don't discuss anything in
the low-volume channel”. I think it makes sense to revive
announcements@ (last post 2014-103?) for the low-volume list (and
possibly to moderate it). Then folks interested in the announcements
from steps 2 and 4 can just subscribe to announcements@ without
worrying about missing out on important decisions.

Thoughts?

[2]: Apologies to
https://archive.org/stream/BookOfCommonPrayer#page/n306/mode/1up

Member

wking commented May 8, 2016

On Sun, May 08, 2016 at 07:01:02AM -0700, C. Titus Brown wrote:

An alternative approach would be to have a policy that essentially
every post to discuss@ gets a github issue automatically created for
it, and nobody replies on list.

You've mentioned the “only post links” approach a few times, but it's
only just sunk in. Thanks for repeating yourself until I noticed what
you were saying :p. I like this approach, since it's easy to explain,
hard to botch, and easy to objectively identify violators (for links
to docs and then eventually bans for repeated violations). I think we
need consensus around where the linked channel should be. Most
discussions will result in a change to a swcarpentry repo, so linking
to a GitHub issue or pull request is probably the right thing to do
(even though I'd prefer email for the reasons listed in 1).

Also, decisions have a way of getting made on high volume lists,
which I think is bad…

I agree that the broader community should be kept abreast of any
decisions, ideally in time to chime in before they are officially
adopted. I'd recommend the usual approach be something like:

  1. Create swcarpentry/$REPO#$ISSUE (or a pull request, or whatever)
    outlining $IDEA.

  2. Post to the low-volume channel:

    Hi everyone,

    I've opened https://github.com/swcarpentry/$REPO/issues/$ISSUE to
    discuss $IDEA. Please join in if you're interested.

  3. Discussion happens in the issue from step 1, and eventually settles
    around a recommended $ACTION.

  4. Post a reply to the step-2 message with:

    We've reached a consensus and plan to take $ACTION on $DATE.
    Therefore if anyone can shew any just cause why this may not be a
    good idea, post to the GitHub issue now, or else hereafter for at
    least six months hold your peace [2].

  5. If new concerns are raised, go back to step 3.

  6. $DATE arrives without new concerns.

  7. $ACTION is taken.

Although in cases where the actor considers the likelyhood or risk of
disagreement small, you can skip straight from step 3 to 7. And for
really minor or serious issue, you can skip straight from step 1 to 7.
And there are probably many other tweaks that are appropriate in a
given situation, with the only important rule as far as volume and
discussion fragmentation are concerned is “don't discuss anything in
the low-volume channel”. I think it makes sense to revive
announcements@ (last post 2014-103?) for the low-volume list (and
possibly to moderate it). Then folks interested in the announcements
from steps 2 and 4 can just subscribe to announcements@ without
worrying about missing out on important decisions.

Thoughts?

[2]: Apologies to
https://archive.org/stream/BookOfCommonPrayer#page/n306/mode/1up

@jttkim

This comment has been minimized.

Show comment
Hide comment
@jttkim

jttkim May 9, 2016

Quoting @ctb

It would be good to articulate clearly and precisely the long-standing (but perhaps rarely specified) goal that this list is meant to be a low volume discuss list. I know @gvwilson (the creator of the list and founder of SCF) has struggled to maintain a balance between participation and deluge, and I know many, many people who have dropped off the list as the volume has grown. To try to articulate it myself, the discuss list is one of the primary information channels for what is going on with Software Carpentry and its associated community of instructors (which now includes Data Carpentry and others), and should be kept for information updates and requests for links, not for broad and opinionated discussion.

I must confess that I was not aware that discuss is meant to be a low-volume list primarily for announcements. The name isn't really suggestive of that to me, not least because many projects have an *-announce list for announcements and a *-discuss list for discussion -- see [1] for a directory of mailing list reflecting this pattern.

I would strongly prefer adopting this dual mailing list pattern. It works well in my experience, and it's the minimum viable solution to the problem of separating low-volume material that's relevant to most from high-volume discussion which people can opt out of if the relevance / volume ratio is too low for them.

Regarding using other platforms I agree with @wking that that should be avoided. Personally, I don't have the time to keep up with everything on GitHub / LinkedIn / Xing / Google+ / Twitter / Facebook / Slack -- I don't even have accounts in the latter two of these, and I don't particularly want yet more accounts. As SWC makes such heavy use of GitHub assuming that everyone is ok with that may make some sense, but I very much advise against creating any pressure to adopt any systems in addtion to email and GitHub.

[1] https://lists.gnu.org/mailman/listinfo

jttkim commented May 9, 2016

Quoting @ctb

It would be good to articulate clearly and precisely the long-standing (but perhaps rarely specified) goal that this list is meant to be a low volume discuss list. I know @gvwilson (the creator of the list and founder of SCF) has struggled to maintain a balance between participation and deluge, and I know many, many people who have dropped off the list as the volume has grown. To try to articulate it myself, the discuss list is one of the primary information channels for what is going on with Software Carpentry and its associated community of instructors (which now includes Data Carpentry and others), and should be kept for information updates and requests for links, not for broad and opinionated discussion.

I must confess that I was not aware that discuss is meant to be a low-volume list primarily for announcements. The name isn't really suggestive of that to me, not least because many projects have an *-announce list for announcements and a *-discuss list for discussion -- see [1] for a directory of mailing list reflecting this pattern.

I would strongly prefer adopting this dual mailing list pattern. It works well in my experience, and it's the minimum viable solution to the problem of separating low-volume material that's relevant to most from high-volume discussion which people can opt out of if the relevance / volume ratio is too low for them.

Regarding using other platforms I agree with @wking that that should be avoided. Personally, I don't have the time to keep up with everything on GitHub / LinkedIn / Xing / Google+ / Twitter / Facebook / Slack -- I don't even have accounts in the latter two of these, and I don't particularly want yet more accounts. As SWC makes such heavy use of GitHub assuming that everyone is ok with that may make some sense, but I very much advise against creating any pressure to adopt any systems in addtion to email and GitHub.

[1] https://lists.gnu.org/mailman/listinfo

@SpacedGirl

This comment has been minimized.

Show comment
Hide comment
@SpacedGirl

SpacedGirl May 9, 2016

I had the same thoughts about the discuss list having the wrong name if primarily for announcements.

My newest thought on this issue was that a new list could be formed Discuss_expanded and it could be used to discuss arcane, not of great use to everyone stuff from the Discuss list and also could be an alternative to github. So when things get moved to github, they also get moved to the expanded list.

Not sure exactly how to inter-relate subsequent stuff that occurs on both github and discuss_expanded but really think it would require an experience based solution. [as in something to be worked out after having both in use for a while]. The solution could be as simple as someone just taking to update the list with github related actions on whatever was moved there.

Also would need to figure out a way to introduce a new subject/thread. [feel like this might actually be an issue if relating two different lists but probably not obviously so. The answer is probably that the subject name need be the same and start with a reference to the original Discuss topic.]

SpacedGirl commented May 9, 2016

I had the same thoughts about the discuss list having the wrong name if primarily for announcements.

My newest thought on this issue was that a new list could be formed Discuss_expanded and it could be used to discuss arcane, not of great use to everyone stuff from the Discuss list and also could be an alternative to github. So when things get moved to github, they also get moved to the expanded list.

Not sure exactly how to inter-relate subsequent stuff that occurs on both github and discuss_expanded but really think it would require an experience based solution. [as in something to be worked out after having both in use for a while]. The solution could be as simple as someone just taking to update the list with github related actions on whatever was moved there.

Also would need to figure out a way to introduce a new subject/thread. [feel like this might actually be an issue if relating two different lists but probably not obviously so. The answer is probably that the subject name need be the same and start with a reference to the original Discuss topic.]

@SpacedGirl

This comment has been minimized.

Show comment
Hide comment
@SpacedGirl

SpacedGirl May 9, 2016

New to github and don't know how to search it well. Also, one of the reasons I dislike it is due to it's horrid user interface for newcomers. Way past the point in the digital age of being willing to spend much time learning how to navigate new software/webware.

The point ---> can someone point me [with a link to its comment section [don't even get me started on github's approach there]] to where this issue is held:

Word and PowerPoint "all wrong"? (#371)

SpacedGirl commented May 9, 2016

New to github and don't know how to search it well. Also, one of the reasons I dislike it is due to it's horrid user interface for newcomers. Way past the point in the digital age of being willing to spend much time learning how to navigate new software/webware.

The point ---> can someone point me [with a link to its comment section [don't even get me started on github's approach there]] to where this issue is held:

Word and PowerPoint "all wrong"? (#371)

@ctb

This comment has been minimized.

Show comment
Hide comment
@ctb

ctb May 9, 2016

On Sun, May 08, 2016 at 02:58:49PM -0700, W. Trevor King wrote:

On Sun, May 08, 2016 at 07:01:02AM -0700, C. Titus Brown wrote:

An alternative approach would be to have a policy that essentially
every post to discuss@ gets a github issue automatically created for
it, and nobody replies on list.

You've mentioned the ???only post links??? approach a few times, but it's
only just sunk in. Thanks for repeating yourself until I noticed what
you were saying :p. I like this approach, since it's easy to explain,
hard to botch, and easy to objectively identify violators (for links
to docs and then eventually bans for repeated violations). I think we
need consensus around where the linked channel should be. Most
discussions will result in a change to a swcarpentry repo, so linking
to a GitHub issue or pull request is probably the right thing to do
(even though I'd prefer email for the reasons listed in [1]).

I personally also prefer e-mail but it just doesn't work for many.

One of the "only post links" ideas is to shunt things to github.

The other approach to curbing high volume and/or angry discussion is to
discourage the posting of "in my experience..." or "I believe..." posts.
Often those seem to devolve into religious wars about something or other.
So we could have a strong prior that a post should either (a) ask a question,
or (b) notify of a resource, and responses to that post should provide
links or references with only a little bit of commentary.

I think both approaches have pluses and minuses, but they are the best
hope I can see for keeping the discuss list manageable.

I like your template!

ctb commented May 9, 2016

On Sun, May 08, 2016 at 02:58:49PM -0700, W. Trevor King wrote:

On Sun, May 08, 2016 at 07:01:02AM -0700, C. Titus Brown wrote:

An alternative approach would be to have a policy that essentially
every post to discuss@ gets a github issue automatically created for
it, and nobody replies on list.

You've mentioned the ???only post links??? approach a few times, but it's
only just sunk in. Thanks for repeating yourself until I noticed what
you were saying :p. I like this approach, since it's easy to explain,
hard to botch, and easy to objectively identify violators (for links
to docs and then eventually bans for repeated violations). I think we
need consensus around where the linked channel should be. Most
discussions will result in a change to a swcarpentry repo, so linking
to a GitHub issue or pull request is probably the right thing to do
(even though I'd prefer email for the reasons listed in [1]).

I personally also prefer e-mail but it just doesn't work for many.

One of the "only post links" ideas is to shunt things to github.

The other approach to curbing high volume and/or angry discussion is to
discourage the posting of "in my experience..." or "I believe..." posts.
Often those seem to devolve into religious wars about something or other.
So we could have a strong prior that a post should either (a) ask a question,
or (b) notify of a resource, and responses to that post should provide
links or references with only a little bit of commentary.

I think both approaches have pluses and minuses, but they are the best
hope I can see for keeping the discuss list manageable.

I like your template!

@wking

This comment has been minimized.

Show comment
Hide comment
@wking

wking May 9, 2016

Member

On Mon, May 09, 2016 at 06:24:13AM -0700, C. Titus Brown wrote:

So we could have a strong prior that a post should either (a) ask a
question, or (b) notify of a resource, and responses to that post
should provide links or references with only a little bit of
commentary.

I think that opens the door too much ;). I'd rather have all posts to
the low-volume list have a clear link to the location in which further
discussion should happen. So:

Hi everyone,

I've opened https://github.com/swcarpentry/faq/issues/123 to get
more clarity on the intended list workflow. Can someone clarify
that for me in a post to the issue?

If we expect answers or counter-links with “a little bit of
commentary” on the low-volume list, I think we get back to our current
gray zone where a list moderator or other member has to take action to
explicitly push the discussion off the low-volume list.

Member

wking commented May 9, 2016

On Mon, May 09, 2016 at 06:24:13AM -0700, C. Titus Brown wrote:

So we could have a strong prior that a post should either (a) ask a
question, or (b) notify of a resource, and responses to that post
should provide links or references with only a little bit of
commentary.

I think that opens the door too much ;). I'd rather have all posts to
the low-volume list have a clear link to the location in which further
discussion should happen. So:

Hi everyone,

I've opened https://github.com/swcarpentry/faq/issues/123 to get
more clarity on the intended list workflow. Can someone clarify
that for me in a post to the issue?

If we expect answers or counter-links with “a little bit of
commentary” on the low-volume list, I think we get back to our current
gray zone where a list moderator or other member has to take action to
explicitly push the discussion off the low-volume list.

@jttkim

This comment has been minimized.

Show comment
Hide comment
@jttkim

jttkim May 9, 2016

@SpacedGirl: the "Word and Powerpoint" discussion has been moved here: swcarpentry/website#371 .

@ctb: is "in my experience" really that bad? I feel guilty now, noticing that I have used that phrase in my reply to you above. Until today I genuinely thought this was an anti-incendiary phrase, indicating that this is my experience only, and if yours is equally valid regardless of whether it differs.

jttkim commented May 9, 2016

@SpacedGirl: the "Word and Powerpoint" discussion has been moved here: swcarpentry/website#371 .

@ctb: is "in my experience" really that bad? I feel guilty now, noticing that I have used that phrase in my reply to you above. Until today I genuinely thought this was an anti-incendiary phrase, indicating that this is my experience only, and if yours is equally valid regardless of whether it differs.

@wking

This comment has been minimized.

Show comment
Hide comment
@wking

wking May 9, 2016

Member

On Mon, May 09, 2016 at 04:50:06PM -0700, Jan T. Kim wrote:

Until today I genuinely thought this was an anti-incendiary phrase,
indicating that this is my experience only, and if yours is equally
valid regardless of whether it differs.

I don't think @ctb claims it's incendiary, it's just a marker for
posts that might trigger discussion. The “only post links” approach
[1,2] pushes all discussion off the low-volume channel into wherever
the low-volume anouncements link (e.g. a GitHub issue).

Member

wking commented May 9, 2016

On Mon, May 09, 2016 at 04:50:06PM -0700, Jan T. Kim wrote:

Until today I genuinely thought this was an anti-incendiary phrase,
indicating that this is my experience only, and if yours is equally
valid regardless of whether it differs.

I don't think @ctb claims it's incendiary, it's just a marker for
posts that might trigger discussion. The “only post links” approach
[1,2] pushes all discussion off the low-volume channel into wherever
the low-volume anouncements link (e.g. a GitHub issue).

@ctb

This comment has been minimized.

Show comment
Hide comment
@ctb

ctb May 10, 2016

"In my experience" can be informative, or not. Either way it just doesn't work well when 10% of 700 subscribers (wow, really? 700?!) chime in. By contrast, in my experience ( :) it is a more productive use of list mindshare to ask for pointers to specific information and/or provide a link to something.

Like (I suspect) you, I am tolerant of high volume mailing lists as long as they are also high signal, which this one is. But we lose a lot of very smart people to the volume of the 'discuss' list, and I wish they would stick around...

ctb commented May 10, 2016

"In my experience" can be informative, or not. Either way it just doesn't work well when 10% of 700 subscribers (wow, really? 700?!) chime in. By contrast, in my experience ( :) it is a more productive use of list mindshare to ask for pointers to specific information and/or provide a link to something.

Like (I suspect) you, I am tolerant of high volume mailing lists as long as they are also high signal, which this one is. But we lose a lot of very smart people to the volume of the 'discuss' list, and I wish they would stick around...

@rgaiacs

This comment has been minimized.

Show comment
Hide comment
@rgaiacs

rgaiacs Jan 15, 2017

Contributor

@wking Thanks for bring this up. This issue is still important? Should we discuss more? Or can we close it?

Contributor

rgaiacs commented Jan 15, 2017

@wking Thanks for bring this up. This issue is still important? Should we discuss more? Or can we close it?

@SpacedGirl

This comment has been minimized.

Show comment
Hide comment
@SpacedGirl

SpacedGirl Jan 16, 2017

SpacedGirl commented Jan 16, 2017

@wking

This comment has been minimized.

Show comment
Hide comment
@wking

wking Jan 16, 2017

Member
Member

wking commented Jan 16, 2017

@ctb

This comment has been minimized.

Show comment
Hide comment
@ctb

ctb commented Jan 17, 2017

@SpacedGirl

This comment has been minimized.

Show comment
Hide comment
@SpacedGirl

SpacedGirl Jan 31, 2017

SpacedGirl commented Jan 31, 2017

@SpacedGirl

This comment has been minimized.

Show comment
Hide comment
@SpacedGirl

SpacedGirl Jan 31, 2017

SpacedGirl commented Jan 31, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment