Re: [discuss] Image processing with Python

[Bennet Fauber]

Carlos,

You might find something in this lesson useful


https://bic-berkeley.github.io/psych-214-fall-2016/arrays_and_images.html

There are also three exercises in the parent lesson,

https://bic-berkeley.github.io/psych-214-fall-2016/day_01.html

As others have said, possibly not appropriate for rank beginners, but maybe
something you can use there.

-- bennet



On Fri, May 25, 2018 at 7:34 AM, Carlos Martinez Ortiz <
c.marti...@esciencecenter.nl> wrote:

> Hello!
>
>
> Does anybody have material for an image processing lesson? I am preparing
> a workshop for a group of people who will mostly be working with image
> analysis and thought it might be good if I can tune the content a little
> bit to make it more interesting to them.
>
>
> Any would be most welcome.
>
>
> Best,
>
> Carlos
>
>
> *|* dr. Carlos Martinez-Ortiz *|*  eScience Research Engineer  *|*
> *|* Netherlands eScience Center *|* www.esciencecenter.nl *|*
>
> *|* *Calls for Contributions IEEE eScience* *|*
>
> *| *We are proud to host *|* 14th IEEE International Conference
> on eScience 2018 *|* *| *29 Oct – 1 Nov 2018 *| *Amsterdam, the
> Netherlands *|* *www.eScience2018.com * *|*
>
> *The Carpentries * / discuss
>  / Permalink
> 
>  Delivery
> options 
>

--
The Carpentries: discuss
Permalink: 
https://carpentries.topicbox.com/groups/discuss/discussions/T4240adcd25206bde-Mbc5f804690b2df7809dd911a
Delivery options: https://carpentries.topicbox.com/groups

Re: [discuss] SQL Database version control tool recommendations?

[Bennet Fauber]

Tiffany,

You might experiment with some smallish databases.  The order of
records may well change significantly from dump to dump, making the
apparent differences and the actual differences between any two dumps
appear much larger than they really are.

Good luck!


On Fri, Aug 10, 2018 at 12:49 PM Tiffany A. Timbers via discuss
 wrote:
>
> Thanks all for your input - very helpful! Dav - happy for you to questions 
> the general strategy. As I said, I know very little about this. In my case 
> its a smallish, simple SQLite database with ~ 8 tables. So 
> dumping/transaction logs/etc might work well and easily. But if there's a 
> better and different strategy for checkpointing SQLite databases, I'd love to 
> learn.
>
> Thanks!
> Tiffany
> The Carpentries / discuss / see discussions + participants + delivery options 
> Permalink

--
The Carpentries: discuss
Permalink: 
https://carpentries.topicbox.com/groups/discuss/Ta7250f4266e508c5-Mb0ae3c22005b6cfbf5866889
Delivery options: https://carpentries.topicbox.com/groups/discuss/subscription

Re: [discuss] SQL Database version control tool recommendations?

[Bennet Fauber]

Where possible, we used to keep transaction logs in addition to
database dumps.  Those can be replayed from the dumped database state
to replay the transactions up to any point by copying and editing the
transaction log(s).

My best recollection is that they are text and would be suitable for
entry into Git.  They are also smaller, and in the case of needing to
recover because of an entry that causes later corruption or problems,
much easier to modify to make corrections or deletions.

What is the purpose of putting the database into Git?  If you create
and keep transaction logs (possibly in Git), and have something akin
to a rakefile that creates the original database structure, then the
database itself becomes a derived file, akin to a .pyc file, and can
be recreated at will, so tracking the database, per se, isn't
necessary.

Just a thought.

-- bennet





On Fri, Aug 10, 2018 at 8:49 AM Greg Wilson  wrote:
>
> Hi Tiffany,
>
> For small SQLite databases, the simplest thing is to dump as SQL text and put 
> that under version control. I've done this with DBs up to 100kb or so, and it 
> allows diff and merge to work as they usually do.  It's...not horrible.  For 
> larger databases, I've seen groups create a database backup using the DBMS's 
> native tool and then use something like Git LFS to manage that backup as a 
> binary blob.  It works, but you then have to use the DBMS's own tools for 
> finding differences and reconciling them.
>
> Cheers,
>
> Greg
>
> On 2018-08-09 10:47 PM, Tiffany A. Timbers via discuss wrote:
>
> Hi folks,
>
> I am looking for SQL Database version control tool recommendations? Ones that 
> work with Git and are open source are ideal. I have never tread in this 
> territory before, so all opinions/options welcome!
>
> Thanks!
> Tiffany
>
>
> --
> If you cannot be brave – and it is often hard to be brave – be kind.
>
> The Carpentries / discuss / see discussions + participants + delivery options 
> Permalink

--
The Carpentries: discuss
Permalink: 
https://carpentries.topicbox.com/groups/discuss/Ta7250f4266e508c5-Mbf1e4c2ac14b8dfcb9781826
Delivery options: https://carpentries.topicbox.com/groups/discuss/subscription

Re: [discuss] Slide of Joel Grus' JupyterCon Talk "I Don't Like Notebooks"

[Bennet Fauber]

Kevin,

Nice summary; thank you.

It is yet another thing to learn in a short time.  I am not a notebook
fan, and I remember attending two workshops at a conference that were
notebook based -- those were my first real experience with notebooks
-- and I had more questions about the mechanics of notebooks than I
did about the material being presented using them.  I thought that
quite counter-productive.



On Tue, Aug 28, 2018 at 12:16 AM Kevin Vilbig via discuss
 wrote:
>
> All,
>
> I do not like Jupyter notebooks for teaching, either and I have been thinking 
> this privately for a while. They carry a lot of cognitive load compared to a 
> straightforward CLI REPL, which we actually tout as the best way to start 
> learning in our materials. I have taught a few SWC workshops and mostly stuck 
> to the CLI and git lessons for that reason. I have taught some DC as well, 
> but those are a different beast and are actually flow a lot more tightly 
> compared to the SWC workshops. I suspect Jupyter notebooks as being the 
> culprit. The notebooks seem good for people who learned to code from MATLAB 
> or Mathematica because they superficially resemble those systems, but that is 
> not most people that we teach nor even necessarily most of our teachers.
>
> I think it would be best practices (especially for the general pedagogical 
> theories that we use) to teach Python at the level of a text file written in 
> the same text editor we use for the other lessons. Then we should be running 
> those scripts as files from the same command lines we use in the other 
> lessons. Iirc this was the case until the lessons were changed to incorporate 
> the Jupyter notebooks. This method would reduce cognitive load and increase 
> mutual scaffolding between the lessons rather than needing a major cognitive 
> gear-shift between CLI work and a browser-based IDE. I always wondered why 
> there seems to be a disconnect between the other lessons where we really do 
> keep it simple. Is it just to have some flashy GUI to show off like we have 
> RStudio for the R lessons?
>
> I would prefer to teach the basics (variables, arrays, etc.) using the Python 
> interpreter running from the command line, how to save and run a script using 
> a text editor from the command line, and using the techniques we taught in 
> other lessons like command line arguments.  If the teacher uses Jupyter in 
> their actual work, they can show off their work if there is extra time, 
> (Maybe we should build a 25-30 minute segment like that into the lesson 
> plan?) but we shouldn't be starting there.
>
> -K
>
> On Mon, Aug 27, 2018 at 1:31 PM Purwanto, Wirawan  wrote:
>>
>> Jory,
>>
>>
>>
>> Great moderating points. I don’t think we should throw Jupyter out of the 
>> window completely, but we need to know how to use this tool.
>>
>>
>>
>> Drawing from my days using ipython: Jupyter is basically a web-based ipython 
>> with lots of candies added. There is one feature of ipython that allows you 
>> to log the “In[NNN]” and the “Out[NNN]” of the python code:
>>
>>
>>
>> %logstart -t -o LOGFILENAME
>>
>>
>>
>> I just checked that this also works on a jupyter session. LOGFILENAME is 
>> just a text log file. After invoking this statement (once, at the beginning 
>> of your python Jupyter session), every input and output will be logged. But 
>> the output of “print” statements or inline graphics (such as pyplot output) 
>> are not saved. (There are tricks to make that happen, but that’s a topic for 
>> another thread.) But this approach allows you to reason the mystery kernel 
>> codes, because ipython logging won’t lie, and won’t be subject to cell 
>> editing (the input/output you deleted on Jupyter will still be there in the 
>> log file). I added “-t” flag to “logstart” magic in order to add timestamp 
>> to the logged inputs, because sometimes I work on a notebook for a long 
>> time, and lose track of when I did what.
>>
>>
>>
>> I would combine real software engineering (i.e. using modules, good coding 
>> practices) for the heavy-lifting codes, and use Jupyter to produce a record 
>> of my interactive session. I don’t put very long codes in Jupyter cells, 
>> because that becomes clutter to me. But again, this would call users to be a 
>> little bit more savvy: to be able to interact with both the modules/other 
>> python source files and the Jupyter notebook at the same time.
>>
>>
>>
>> --
>>
>> Wirawan Purwanto
>>
>> Computational Scientist, Research Computing Group
>>
>> Information Technology Services
>>
>> Old Dominion University
>>
>> Norfolk, VA 23529
>>
>>
>>
>> From: Jory Schossau via discuss 
>> Reply-To: discuss 
>> Date: Saturday, August 25, 2018 at 10:04 AM
>> To: "discuss@lists.carpentries.org" 
>> Subject: Re: [discuss] Slide of Joel Grus' JupyterCon Talk "I Don't Like 
>> Notebooks"
>>
>>
>>
>> I agree with most of the points everyone's making here, and just wanted to 
>> add some from my experiences as I both teach and use 

Re: [discuss] Slide of Joel Grus' JupyterCon Talk "I Don't Like Notebooks"

[Bennet Fauber]

Carol,

I don't think anyone is saying, "Tell people not to use notebooks."
The questions are about whether they improve the learning experience
for beginners.  There is also the question of whether use of the GUI
somehow defeats the purpose of the shell lesson by contradicting what
is often said there; namely, the command line is a powerful tool, you
should use it.

One respondent said they review ways to run python -- python, ipython,
jupyter -- then go on to use whatever in their workshop.  That goes
some way toward giving the participants choices.  It may not
counteract the message that is still implicit or implicit in the shell
lesson.

Perhaps the shell lesson should be modified so that the shell is
treated as a data management tool, and notebooks and Rstudio are
treated as development environments?  Then the dissonance between
advocating the shell in one lesson and abandoning it in another would
be lessened?

Perhaps all it would take would be a couple of examples of running a
notebook from the command line and telling it to start from scratch
and run all cells.  If a notebook can be run in the same way from a
prompt that a .py file can be, then maybe showing that capability
solves a whole bunch of problems.

The out-of-phase evaluation of things that is possible in notebooks
can also lead to irreproducible results, which is not, I think, in
keeping with the goals of the Carpentries.

Some people will want to keep notebooks, and others will want to
forego them; there should be a place for both approaches, and the one
that best fits the goal of the particular offering and the expected
audience should be chosen.  I think it would not be a service to
future learners if only one way were available for all circumstances.

Perhaps it would help to consider a full two-day workshop as a bundle,
and pick the lesson components that leads to the most coherent and
clear presentation of the most important points to the targeted
audience?  That would lesson the dissonance between command-line for
shell/git and GUI for R/Python, maybe?  Should there be an option to
do GUI-only workshops, no shell and a GUI for Git?  Similarly, a
command-line only option.  I think that might be worth considering.

On Tue, Aug 28, 2018 at 6:31 PM Carol Willing
 wrote:
>
> Hi all,
>
> There's positive discussion that has been started by Joel's talk. While I 
> liked his talk and there are some good points re: improving support for 
> software engineering best practices in Jupyter and JupyterLab notebooks, I'm 
> a bit concerned about the direction that this conversation is going.
>
> While all are entitled to their personal opinions and the Carpentries will 
> use notebooks when and if needed, I believe that the Carpentries would be 
> doing its students a disservice by warning people not to use the notebooks or 
> conda.
>
> The notebooks are a popular and effective tool for scientists and data 
> scientists to have in their toolbox. Project Jupyter won the ACM Software 
> System Award recently, and the ACM stated "These tools, which include 
> IPython, the Jupyter Notebook and JupyterHub, have become a de facto standard 
> for data analysis in research, education, journalism and industry." 
> https://awards.acm.org/software-system
>
> While it's great for folks to have different personal perspectives, I want to 
> make sure that the Carpentries and its lessons do not recommend that the 
> Jupyter Notebooks, IPython, and JupyterHub should be avoided by scientists 
> and data scientists.
>
> Thanks,
>
> Carol Willing
>
>
> > On 28 Aug 2018, at 11:38, Maxime Boissonneault 
> >  wrote:
> >
> > These kinds of things are rather hard to track in time, because everything 
> > is a moving target (conda and other package managers constantly get 
> > updated, but also version of packages changes), but here is a bit more 
> > details :
> >
> > - The 10x performance difference was with a user code, which I 
> > unfortunately can't share (nor do I still have a copy of it). It was about 
> > numpy, which may or may not have changed since MKL can now be shipped with 
> > Anaconda.
> >
> > - FFTW, 2x performance gain : These slides compare between Conda-provided 
> > (and those provided by other package managers) FFTW, and one which was 
> > built on an avx2 cluster, the performance gain is 2x (see slides 28 and 29 :
> > https://archive.fosdem.org/2018/schedule/event/installing_software_for_scientists/attachments/slides/2437/export/events/attachments/installing_software_for_scientists/slides/2437/20180204_installing_software_for_scientists.pdf
> >
> >
> > - Tensorflow, 7x gain for CPU version, slide 28 of this talk : 
> > https://archive.fosdem.org/2018/schedule/event/how_to_make_package_managers_cry/attachments/slides/2297/export/events/attachments/how_to_make_package_managers_cry/slides/2297/how_to_make_package_managers_cry.pdf
> >
> >   This one was not comparing Conda itself, but manylinux python wheels 
> > provided by the Tensorflow team, 

Re: [discuss] What's in a name: Live-Coding, or?

[Bennet Fauber]

Lex,

It could be a noun.  People refer to a sing-along as an event; I have been
invited to some other musical play-alongs aimed at beginning
instrumentalists.  Probably worth defining once, then use it well.  :-)

-- bennet



On Mon, Oct 22, 2018 at 10:23 AM Lex Nederbragt 
wrote:

> Thanks for the 'code-along' suggestion. I like it, it sounds great!
> However, I am not sure how to use it in practice to describe our teaching
> method as it seems to be meant as adjective, not a noun. For example, we
> currently write:
>
> "One of the cornerstones of Software and Data Carpentry teaching is live
> coding"
>
> We can’t hardly change that to ‘is code-along’. We could use ‘is a
> code-along style of interactive programming’, but that becomes too long
> again… ‘is code-along sessions’ doesn’t work too well either. Oh, and ‘is
> code-along live coding’ sounds weird.
>
> So I like it as an adjective describing the style of teaching, but feel
> I’m still looking for a better noun, or better adjective between ‘live’ and
> ‘coding’.
>
> Lex
>
>
> On 15 Oct 2018, at 17:24, Hoyt, Peter  wrote:
>
> +1
>
> Peter Hoyt
>
> On 10/15/2018 10:12 AM, Erin Becker wrote:
>
> I love code-along!
>
> On Mon, Oct 15, 2018 at 5:19 AM Jeremy Metz via discuss <
> discuss@lists.carpentries.org> wrote:
>
>> +1 for code-along - short but descriptive, and also informal and fun
>> sounding!
>>
>> On Mon, 15 Oct 2018 at 13:04, Adriana De Palma 
>> wrote:
>>
>>> Code-along. As in sing-along. As in fun ☺
>>>
>>>
>>>
>>> *From:* Lex Nederbragt [mailto:lex.nederbr...@ibv.uio.no]
>>> *Sent:* 15 October 2018 12:49
>>> *To:* Discuss list Carpentries 
>>> *Subject:* [discuss] What's in a name: Live-Coding, or?
>>>
>>>
>>> Hi,
>>>
>>>
>>> I have for a while been thinking about the term ‘live-coding’ as we use
>>> it as our teaching approach in workshops. What we mean is a form of
>>> teaching described in the instructor training material
>>>  as
>>> “work[ing] through the lesson material, typing in the code or instructions,
>>> with the workshop participants following along”. But there are other
>>> meanings of the term, for example, some people will ‘live code’ a software
>>> demo during a conference, without the participants doing any coding
>>> themselves. Apparently it even can be done as a performing arts form
>>> (creating sounds, images, etc)- see the wikipedia entry on ‘Live coding'.
>>>
>>>
>>> I am looking for a term that better describes what we do. Examples I
>>> have considered:
>>>
>>>
>>> -* live follow-along coding*; however, follow-along does not imply
>>> learners being active, they could just as well sit back, relax and follow
>>> along closely (note that the description from the instructor training
>>> material uses this wording also)
>>>
>>> - *live interactive coding*; however, there is not much interaction
>>> unless for any truly *interactive* exercises
>>>
>>> - *live together-coding* or *live collaborative coding*; however, we
>>> are not really coding together or collaboratively, learners merely mirror
>>> the instructor (except for when they do exercises); still, these are
>>> currently my favourites
>>>
>>>
>>> Any other suggestions?
>>>
>>>
>>> Best,
>>>
>>>
>>> Lex
>>>
>>>
>>>
>
> --
> Associate Director, The Carpentries
> Pronouns: she/her/hers
>
>
>
> *The Carpentries * / discuss /
> see discussions  +
> participants  + 
> delivery
> options 
> Permalink
> 
>

--
The Carpentries: discuss
Permalink: 
https://carpentries.topicbox.com/groups/discuss/T69368b0ceffc20b9-Md3ae1863a21cab63fcdda76a
Delivery options: https://carpentries.topicbox.com/groups/discuss/subscription

Re: [discuss] NLP Carpentry

[Bennet Fauber]

Agreed.

Slack is not a good place for persistent, open conversations that will
end up shaping how lessons, code, and policies are implemented.  At my
day job, we have several years of lost conversations, policy
decisions, and links to useful things that disappeared into the
history that isn't displayed without paying.  Not a good tool for
things it's not good at.

It is good for things that can be dealt with quickly and that do not
need long-term recollection or that will have ramifications beyond a
few days.  Good tool for what it's good at.


On Mon, Jul 22, 2019 at 2:06 PM Dav Clark  wrote:
>
> I resonate strongly with this "Why I Avoid Slack" article from Matthew 
> Rocklin, who has a pretty good track record of fostering open source 
> community:
>
> https://matthewrocklin.com/blog/2019/02/28/slack-github
>
> I think an email archive also has good affordances, especially for putting 
> together a curriculum vs. a software project.
>
> But I'll try to keep up with whatever the broader group wants to do.
>
> D
>
> On Mon, Jul 22, 2019 at 8:50 AM Deborah Paul  wrote:
>>
>> Maybe good to have a Slack channel in the Carpentries Slack account?
>> Deb
>>
>> On 2019-07-22 11:40 AM, Dav Clark wrote:
>>
>> So it seems maybe there is no working group. Shall we make something to keep 
>> communication organized? Or just use this thread?
>>
>> D
>>
>> On Mon, Jul 22, 2019, 8:28 AM Shoaib Ahmed Sufi 
>>  wrote:
>>>
>>> Hi,
>>>
>>> I just thought I would mentioned this course - 
>>> https://www.fast.ai/2019/07/08/fastai-nlp/ that might be a useful ‘extra 
>>> reading’ or data point for your preparation - I am not an Natural Language 
>>> Processing person but I heard this course being mentioned and lauded 
>>> recently.
>>>
>>> Best
>>> Shoaib
>>>
>>> On 19 Jul 2019, at 17:10, ba...@staffmail.ed.ac.uk wrote:
>>>
>>> Hi all,
>>>
>>> just to let you know ... I'm planning to prepare a carpentries style course 
>>> on text mining... which is a type of NLP (i.e. Natural Language 
>>> Processing). :-)
>>>
>>> Bea Alex (Edinburgh)
>>>
>>>
>>
>> --
>> -- Upcoming iDigBio Events https://www.idigbio.org/calendar
>> -- Deborah Paul, iDigBio Digitization and Workforce Development Manager
>> iDigBio -- Steering Committee Member
>> SPNHC Liaison, Member-At-Large and Member International Relations Committee
>> SYNTHESYS3 Representative, ICEDIG External Advisory Board Member
>> Vice Chair, Biodiversity Information Standards Organisation (TDWG)(2019-2020)
>> Institute for Digital Information, 234 LSB
>> Florida State University
>> Tallahassee, Florida 32306
>> 850-644-6366
>
> The Carpentries / discuss / see discussions + participants + delivery options 
> Permalink

--
The Carpentries: discuss
Permalink: 
https://carpentries.topicbox.com/groups/discuss/Tee8f460df4206334-M0a889cc34f631a6fc27afa73
Delivery options: https://carpentries.topicbox.com/groups/discuss/subscription

Re: [discuss] Undergraduate Workshop on Topology for Data Science

[Bennet Fauber]

Please do post the content and let us know where to retrieve it.  Sounds
quite interesting.


On Sat, Dec 7, 2019 at 8:49 PM Dave Millman  wrote:

> Unfortunately, not this iteration but we will post the content.  If the
> workshop is successful, we hope to do more of them and can look into
> streaming those.
>
> Thank you for the suggestion!
>
>
> On Fri, Dec 6, 2019 at 12:19 PM Mauricio Vargas 
> wrote:
>
>> Hi Dave
>>
>> I find to be of my great interest! Will it be streamed?
>> —
>>
>> *Mauricio Vargas Sepúlveda 帕夏*
>> Do you like Data Science? visit pacha.hk
>> 你爱科学数据专吗？你走pacha.hk
>>
>>
>> On Fri, Dec 6, 2019 at 3:37 PM Dave Millman  wrote:
>>
>>> I am happy to share with you a "Topology for Data Science" workshop that
>>> my colleagues and I will host the day before NCUR 2020.  Please help to
>>> spread the word!!
>>>
>>> *On March 25, 2020*, the Topology for Data Science (T4DS) workshop will
>>> immerse 50 undergraduate students in the fast-growing area of data science,
>>> through the lens of topology. The workshop will be held at the Bozeman
>>> Public Library in Bozeman, MT, the day before Montana State University
>>> hosts the National Conference on Undergraduate Research (NCUR). T4DS will
>>> start with an overview of how to "think with data" through data exploration
>>> and visualization in R, continuing with a brief journey into the field of
>>> topology and how to use topological descriptors to summarize data. In the
>>> afternoon, students will investigate how to cluster data based on those
>>> topological descriptors, and will apply what they've learned to a new data
>>> set. The day will conclude with a reception, where a panel of five faculty
>>> members representing topology and data science will discuss their
>>> experiences with including undergraduates in research and potential career
>>> opportunities in data science.
>>>
>>> All undergraduates are encouraged to apply, regardless of major. The
>>> only prerequisite is a level of mathematics or computer science equivalent
>>> to a first year undergraduate course sequence, and a desire to try
>>> something new! Travel funding is available for up to 25 workshop
>>> participants. The conference website and workshop application can be found
>>> at http://www.montana.edu/datascience. *Priority will be given to
>>> applications received before December 15.*
>>>
>>> If you are a faculty member and would be interested in being on the
>>> panel, please contact us using the email below.
>>>
>>> Please feel free to forward this email or distribute the attached flyer
>>> as you see fit.
>>>
>>> We look forward to taking you on this journey through the topological
>>> data analysis cycle!
>>>
>>> Organizers Stacey Hancock, David Millman, Brittany Fasy, and Veronika
>>> Stranadova-Neeley
>>> email: datascie...@montana.edu
>>>
>> *The Carpentries * / discuss /
> see discussions  +
> participants  + 
> delivery
> options 
> Permalink
> 
>

--
The Carpentries: discuss
Permalink: 
https://carpentries.topicbox.com/groups/discuss/Td8399e9a46b3a9d5-M2fd9a65a7aba3b1ef306fa89
Delivery options: https://carpentries.topicbox.com/groups/discuss/subscription

Re: [discuss] <== Mailing list prefix label for the Carpentries' discuss list

[Bennet Fauber]

It's very 'pre merge', but the old three-letter acronym 'SWC' was
fairly unique, fairly informative, and fairly short.  Would it be out
of court to suggest resuscitating that for this purpose?

One other possibility would be to simply replace 'discuss' with 'carpentry'?




On Tue, Apr 7, 2020 at 11:28 AM Henry Neeman (please use my OU email
address)  wrote:
>
>
>
> I agree that "Carpentries" is too long and "discuss" is too vague.
>
>
> How about something like this?
>
>
> carpsdisc
>
>
> That's 2 characters longer than "discuss" and would be
> opaque to a non-Carpentries person, but would presumably
> be easily understood by someone on this mailing list,
> at least after the first few e-mails they got.
>
>
> Henry Neeman (hnee...@ou.edu)
>
>
> --
>
>
>
> On Tue, Apr 7, 2020 at 10:16 AM Purwanto, Wirawan  wrote:
>> 
>> Hi Kevin, this is just my opinion:: one reason not to add “Carpentries” in 
>> the subject line is to avoid making the prefix too long. Then we couldn’t 
>> easily see what’s the discussion about if we are skimming thru the emails by 
>> the subject line. Especially on small devices like phones. Many mailers are 
>> smart enough to sort out mails to different folders based on the destination 
>> (which can be helpful to maximize focus) – the discuss mails always have 
>> discuss@lists.carpentries.org destination address. Perhaps for mailers to be 
>> smarter in giving visual cues, like colors (ok for those not colorblind), or 
>> tiny icons.
>> 
>> Wirawan
>> 
>> From: "Strong, Dena L" 
>> Reply-To: discuss 
>> Date: Tuesday, April 7, 2020 at 9:09 AM
>> To: discuss 
>> Subject: RE: [discuss] <== Mailing list prefix label for the Carpentries' 
>> discuss list
>> 
>> In my mail client, that would only leave about 10 letters of the actual 
>> topic visible in the left preview pane. Is there anything shorter than the 
>> word Carpentries that could be used?
>> 
>> Sent from Mail for Windows 10
>> 
>> From: Kevin Buckley
>> Sent: Monday, April 6, 2020 8:21 PM
>> To: 'discuss@lists.carpentries.org'
>> Subject: [discuss] <== Mailing list prefix label for the Carpentries' 
>> discuss list
>> 
>> Hi there,
>> 
>> just re-subscribed to "The Carpentries: discuss" list, having realised I'd
>> left myself subscribed at an address associated with my previous job, and
>> so it's just dawned on me that, when viewed in a list of Subject lines,
>> the Carpentries' discuss list emails just show as, eg:
>> 
>> [discuss] Post-workshop eval questions related to online delivery?
>> 
>> and so I was wondering if there was any reason why the mailing list
>> prefix label couldn't explictly mention the Carpentries?
>> 
>> Perhaps
>> 
>> [Carpentries discuss] Post-workshop eval questions related to online 
>> delivery?
>> 
>> or similar would serve to add some context.
>> 
>> As things stand, it's akin to a mailing list equivalent of supplying
>> a phone number in an email sig, but without the country code.
>> 
>
> The Carpentries / discuss / see discussions + participants + delivery options 
> Permalink

--
The Carpentries: discuss
Permalink: 
https://carpentries.topicbox.com/groups/discuss/T180fa0d50619dfc5-M71895bf13387b2d747ac4d9e
Delivery options: https://carpentries.topicbox.com/groups/discuss/subscription