REQ: HOWTO mailing lists resources
What are some good resources for learning how to mailing list? Was: "Re: [Edu-sig] Python teacher notes, preparing for class..." On Thursday, August 30, 2018, Wes Turner <wes.turner@gmail.com> wrote:
Mailing list tips and tricks, PEPs, Write the Docs
Since you asked, although this isn't in scope of the original subject line, and since I'd like to just continue this thread instead of breaking the thread by changing the subject line, and since this isn't technically OT (off-topic) in the interest of conversing toward an objective, here I've added a first-line summary of this message. I should probably change the subject and start a new thread.
You can search mailing lists in a number of ways:
- Google search with "site:mail.python.org" and/or "inurl:" queries https://www.google.com/search?q=site%3Amail.python.org (inurl doesn't match mm3-migrated lists too)
- Google Groups, if the list is set up there too
- Gmail "list:python.org" queries - This doesn't find messages that you didn't receive because you weren't subscribed yet.
- "from:list@mail.python.org" queries - This doesn't find messages that you didn't receive because you weren't subscribed yet.
- Markmail "list:org.python.edu-sig" queries https://markmail.org/search/?q=list%3Aorg.python https://markmail.org/search/?q=list%3Aorg.python.edu-sig
The Python mailing lists aren't yet all upgraded to mailman 3 (/mm3/ URLs); so some lists have the classic mailman archive interface (where "by thread" breaks at the month boundary, for example) and upgraded lists have the new Django-based HyperKitty interface with e.g. search and a full thread view.
With mm3, it's also possible to reply to threads you didn't receive because you weren't subscribed at the time.
e.g. -- for example i.e. -- that is (List of acronyms OTOH/OTOMH)
Reply-all is unnecessary, but often helpful. If you just click reply, it may be addressed off-list to only the sender (and not the list email address, which is what you want if you want the mailing list app to archive for and relay the message to every subscriber). If that happens, you (or the recipient) can forward the message to the list, but it'll be unnecessarily quote-indented unless you just copy and paste (which can be lossy with HTML quote indents inferred from plaintext-quoted lines that start with '>'), so it pays to verify the to: field before you start composing a message.
Some old hands argue for like 72 character fixed width messages so that when they're n-levels quote-indented, they still fit on an 80 character terminal without rewrapping. Old-school email clients like mutt, for example, can handle this; though, on a phone, fixed width hard-broken lines wrap like this sometimes; which is not as easy to read.
TL;DR (too long; didn't read) is an acronym of Reddit; though the standard form of intro summary, body, conclusion summary is equally helpful for long-form mailing list posts. Many email clients show the first part of the first line of the message after the overly-long narrowly descriptive subject line that doesn't actually describe the scope of the discussion anymore.
For Python features, the ultimate objective is to write or develop a PEP. There is a PEP template here: https://www.python.org/dev/peps/pep-0012/ https://github.com/python/peps/blob/master/pep-0012.rst
PEP 1 explains PEPs: "PEP 1 -- PEP Purpose and Guidelines" https://www.python.org/dev/peps/pep-0001/ https://github.com/python/peps/blob/master/pep-0001.txt
PEPs must be justified (as indicated by the Rationale heading in the PEP template); so starting with a justification is a good approach to arguing that you need the whole list's time before you spend your precious time writing an actual PEP like actual contributors do sometimes (when they're getting actual work done).
Bug and issue discussions are for the issue tracker (Roundup), though sometimes it's a really good idea to ask a list for help and feedback.
Mailing lists don't support ReStructuredText, but docs, docstrings, and PEPs do; so it's perfectly reasonable -- even advisable, though not at all strictly necessary -- to format mailing list messages that would be helpful for those purposes in reStructuredText from the start. By the time you've added RST setext headings, you might as well be collaboratively drafting a PEP.
Though it doesn't happen nearly frequently enough, it's often really helpful to update the docs with wisdom culled from the mailing lists (and Q&A sites which have labels).
"6. Helping with Documentation¶" https://devguide.python.org/docquality/
"7. Documenting Python¶" https://devguide.python.org/documenting/
The ultimate source of Python documentation (an often-cited strength of Python as a language choice): https://github.com/python/cpython/tree/master/Doc
"16. Accepting Pull Requests¶" https://devguide.python.org/committing/
On Thursday, August 30, 2018, Wes Turner <wes.turner@gmail.com> wrote:
On Thursday, August 30, 2018, kirby urner <kirby.urner@gmail.com> wrote:
Thanks. Yes, I'll add some links to the docs as you suggest. Great feedback!
Glad to be helpful.
I've trimmed out the text I'm not replying to and tried to use plaintext only in order to: make sure the thread stays below the 40K limit, and make it easy to reply inline without breaking HTML tags.
Actually as part of my class I'm showing them edu-sig and other python.org lists, so we were actually viewing this conversation. I'll extend that to showing your corrections, as I want to demonstrate how the Python community all teaches each other, is friendly and so on.
Code review with pull requests / merge requests and GitHub, Gerrit, GitLab etc is an essential skill.
Src: https://github.com/jupyter/nbdime Docs: https://nbdime.readthedocs.io/
nbdime provides tools for diffing and merging of Jupyter Notebooks.
There are a number of real-time collaborative platforms for working with notebooks (CoCalc, Colab, )
https://hypothes.is highlights and annotations work on anything with a URL, are threaded, and support Markdown.
Kirby
On Thursday, August 30, 2018, Wes Turner <wes.turner@gmail.com> wrote:
Was: "Re: [Edu-sig] Python teacher notes, preparing for class..."
Here's a link to the thread this is forked from: https://mail.python.org/pipermail/edu-sig/2018-August/012007.html https://markmail.org/search/?q=list%3Aorg.python.edu-sig#query:list%3Aorg.py...
On Thursday, August 30, 2018, Wes Turner <wes.turner@gmail.com> wrote:
Mailing list tips and tricks, PEPs, Write the Docs
Since you asked, although this isn't in scope of the original subject line, and since I'd like to just continue this thread instead of breaking the thread by changing the subject line, and since this isn't technically OT (off-topic) in the interest of conversing toward an objective, here I've added a first-line summary of this message. I should probably change the subject and start a new thread.
You can search mailing lists in a number of ways:
- Google search with "site:mail.python.org" and/or "inurl:" queries https://www.google.com/search?q=site%3Amail.python.org (inurl doesn't match mm3-migrated lists too)
- Google Groups, if the list is set up there too
- Gmail "list:python.org" queries - This doesn't find messages that you didn't receive because you weren't subscribed yet.
- "from:list@mail.python.org" queries - This doesn't find messages that you didn't receive because you weren't subscribed yet.
- Markmail "list:org.python.edu-sig" queries https://markmail.org/search/?q=list%3Aorg.python https://markmail.org/search/?q=list%3Aorg.python.edu-sig
The Python mailing lists aren't yet all upgraded to mailman 3 (/mm3/ URLs); so some lists have the classic mailman archive interface (where "by thread" breaks at the month boundary, for example) and upgraded lists have the new Django-based HyperKitty interface with e.g. search and a full thread view.
With mm3, it's also possible to reply to threads you didn't receive because you weren't subscribed at the time.
e.g. -- for example i.e. -- that is (List of acronyms OTOH/OTOMH)
Reply-all is unnecessary, but often helpful. If you just click reply, it may be addressed off-list to only the sender (and not the list email address, which is what you want if you want the mailing list app to archive for and relay the message to every subscriber). If that happens, you (or the recipient) can forward the message to the list, but it'll be unnecessarily quote-indented unless you just copy and paste (which can be lossy with HTML quote indents inferred from plaintext-quoted lines that start with '>'), so it pays to verify the to: field before you start composing a message.
Some old hands argue for like 72 character fixed width messages so that when they're n-levels quote-indented, they still fit on an 80 character terminal without rewrapping. Old-school email clients like mutt, for example, can handle this; though, on a phone, fixed width hard-broken lines wrap like this sometimes; which is not as easy to read.
TL;DR (too long; didn't read) is an acronym of Reddit; though the standard form of intro summary, body, conclusion summary is equally helpful for long-form mailing list posts. Many email clients show the first part of the first line of the message after the overly-long narrowly descriptive subject line that doesn't actually describe the scope of the discussion anymore.
For Python features, the ultimate objective is to write or develop a PEP. There is a PEP template here: https://www.python.org/dev/peps/pep-0012/ https://github.com/python/peps/blob/master/pep-0012.rst
PEP 1 explains PEPs: "PEP 1 -- PEP Purpose and Guidelines" https://www.python.org/dev/peps/pep-0001/ https://github.com/python/peps/blob/master/pep-0001.txt
PEPs must be justified (as indicated by the Rationale heading in the PEP template); so starting with a justification is a good approach to arguing that you need the whole list's time before you spend your precious time writing an actual PEP like actual contributors do sometimes (when they're getting actual work done).
Bug and issue discussions are for the issue tracker (Roundup), though sometimes it's a really good idea to ask a list for help and feedback.
Mailing lists don't support ReStructuredText, but docs, docstrings, and PEPs do; so it's perfectly reasonable -- even advisable, though not at all strictly necessary -- to format mailing list messages that would be helpful for those purposes in reStructuredText from the start. By the time you've added RST setext headings, you might as well be collaboratively drafting a PEP.
Though it doesn't happen nearly frequently enough, it's often really helpful to update the docs with wisdom culled from the mailing lists (and Q&A sites which have labels).
"6. Helping with Documentation¶" https://devguide.python.org/docquality/
"7. Documenting Python¶" https://devguide.python.org/documenting/
The ultimate source of Python documentation (an often-cited strength of Python as a language choice): https://github.com/python/cpython/tree/master/Doc
"16. Accepting Pull Requests¶" https://devguide.python.org/committing/
On Thursday, August 30, 2018, Wes Turner <wes.turner@gmail.com> wrote:
On Thursday, August 30, 2018, kirby urner <kirby.urner@gmail.com> wrote:
Thanks. Yes, I'll add some links to the docs as you suggest. Great feedback!
Glad to be helpful.
I've trimmed out the text I'm not replying to and tried to use plaintext only in order to: make sure the thread stays below the 40K limit, and make it easy to reply inline without breaking HTML tags.
Actually as part of my class I'm showing them edu-sig and other python.org lists, so we were actually viewing this conversation. I'll extend that to showing your corrections, as I want to demonstrate how the Python community all teaches each other, is friendly and so on.
Code review with pull requests / merge requests and GitHub, Gerrit, GitLab etc is an essential skill.
Src: https://github.com/jupyter/nbdime Docs: https://nbdime.readthedocs.io/
nbdime provides tools for diffing and merging of Jupyter Notebooks.
There are a number of real-time collaborative platforms for working with notebooks (CoCalc, Colab, )
https://hypothes.is highlights and annotations work on anything with a URL, are threaded, and support Markdown.
Kirby
Devguide /search "mailing" "12. Following Python’s Development¶" > mailing lists https://devguide.python.org/communication/#mailing-lists - List of development-relevant lists "2. Where to Get Help¶" > Mailing Lists https://devguide.python.org/help/#mailing-lists - [x] python-ideas - [x] python-dev - [ ] tutor "Python Community Code of Conduct" https://www.python.org/psf/codeofconduct/ But where does it teach me TO mailing list? I think that's the real question here. On Thursday, August 30, 2018, Wes Turner <wes.turner@gmail.com> wrote:
On Thursday, August 30, 2018, Wes Turner <wes.turner@gmail.com> wrote:
Was: "Re: [Edu-sig] Python teacher notes, preparing for class..."
Here's a link to the thread this is forked from: https://mail.python.org/pipermail/edu-sig/2018-August/012007.html
https://markmail.org/search/?q=list%3Aorg.python.edu-sig# query:list%3Aorg.python.edu-sig+page:1+mid:wbvjeinflkndz4ey+state:results
On Thursday, August 30, 2018, Wes Turner <wes.turner@gmail.com> wrote:
Mailing list tips and tricks, PEPs, Write the Docs
Since you asked, although this isn't in scope of the original subject line, and since I'd like to just continue this thread instead of breaking the thread by changing the subject line, and since this isn't technically OT (off-topic) in the interest of conversing toward an objective, here I've added a first-line summary of this message. I should probably change the subject and start a new thread.
You can search mailing lists in a number of ways:
- Google search with "site:mail.python.org" and/or "inurl:" queries https://www.google.com/search?q=site%3Amail.python.org (inurl doesn't match mm3-migrated lists too)
- Google Groups, if the list is set up there too
- Gmail "list:python.org" queries - This doesn't find messages that you didn't receive because you weren't subscribed yet.
- "from:list@mail.python.org" queries - This doesn't find messages that you didn't receive because you weren't subscribed yet.
- Markmail "list:org.python.edu-sig" queries https://markmail.org/search/?q=list%3Aorg.python https://markmail.org/search/?q=list%3Aorg.python.edu-sig
The Python mailing lists aren't yet all upgraded to mailman 3 (/mm3/ URLs); so some lists have the classic mailman archive interface (where "by thread" breaks at the month boundary, for example) and upgraded lists have the new Django-based HyperKitty interface with e.g. search and a full thread view.
With mm3, it's also possible to reply to threads you didn't receive because you weren't subscribed at the time.
e.g. -- for example i.e. -- that is (List of acronyms OTOH/OTOMH)
Reply-all is unnecessary, but often helpful. If you just click reply, it may be addressed off-list to only the sender (and not the list email address, which is what you want if you want the mailing list app to archive for and relay the message to every subscriber). If that happens, you (or the recipient) can forward the message to the list, but it'll be unnecessarily quote-indented unless you just copy and paste (which can be lossy with HTML quote indents inferred from plaintext-quoted lines that start with '>'), so it pays to verify the to: field before you start composing a message.
Some old hands argue for like 72 character fixed width messages so that when they're n-levels quote-indented, they still fit on an 80 character terminal without rewrapping. Old-school email clients like mutt, for example, can handle this; though, on a phone, fixed width hard-broken lines wrap like this sometimes; which is not as easy to read.
TL;DR (too long; didn't read) is an acronym of Reddit; though the standard form of intro summary, body, conclusion summary is equally helpful for long-form mailing list posts. Many email clients show the first part of the first line of the message after the overly-long narrowly descriptive subject line that doesn't actually describe the scope of the discussion anymore.
For Python features, the ultimate objective is to write or develop a PEP. There is a PEP template here: https://www.python.org/dev/peps/pep-0012/ https://github.com/python/peps/blob/master/pep-0012.rst
PEP 1 explains PEPs: "PEP 1 -- PEP Purpose and Guidelines" https://www.python.org/dev/peps/pep-0001/ https://github.com/python/peps/blob/master/pep-0001.txt
PEPs must be justified (as indicated by the Rationale heading in the PEP template); so starting with a justification is a good approach to arguing that you need the whole list's time before you spend your precious time writing an actual PEP like actual contributors do sometimes (when they're getting actual work done).
Bug and issue discussions are for the issue tracker (Roundup), though sometimes it's a really good idea to ask a list for help and feedback.
Mailing lists don't support ReStructuredText, but docs, docstrings, and PEPs do; so it's perfectly reasonable -- even advisable, though not at all strictly necessary -- to format mailing list messages that would be helpful for those purposes in reStructuredText from the start. By the time you've added RST setext headings, you might as well be collaboratively drafting a PEP.
Though it doesn't happen nearly frequently enough, it's often really helpful to update the docs with wisdom culled from the mailing lists (and Q&A sites which have labels).
"6. Helping with Documentation¶" https://devguide.python.org/docquality/
"7. Documenting Python¶" https://devguide.python.org/documenting/
The ultimate source of Python documentation (an often-cited strength of Python as a language choice): https://github.com/python/cpython/tree/master/Doc
"16. Accepting Pull Requests¶" https://devguide.python.org/committing/
On Thursday, August 30, 2018, Wes Turner <wes.turner@gmail.com> wrote:
On Thursday, August 30, 2018, kirby urner <kirby.urner@gmail.com> wrote:
Thanks. Yes, I'll add some links to the docs as you suggest. Great feedback!
Glad to be helpful.
I've trimmed out the text I'm not replying to and tried to use plaintext only in order to: make sure the thread stays below the 40K limit, and make it easy to reply inline without breaking HTML tags.
Actually as part of my class I'm showing them edu-sig and other python.org lists, so we were actually viewing this conversation. I'll extend that to showing your corrections, as I want to demonstrate how the Python community all teaches each other, is friendly and so on.
Code review with pull requests / merge requests and GitHub, Gerrit, GitLab etc is an essential skill.
Src: https://github.com/jupyter/nbdime Docs: https://nbdime.readthedocs.io/
nbdime provides tools for diffing and merging of Jupyter Notebooks.
There are a number of real-time collaborative platforms for working with notebooks (CoCalc, Colab, )
https://hypothes.is highlights and annotations work on anything with a URL, are threaded, and support Markdown.
Kirby
But where does it teach me TO mailing list? I think that's the real question here.
Just to clarify what you're asking, here's a use case: I was a volunteer Clerk of IT for a religious group that conducts business on-line but mostly by stowing information at a website, with all the headaches of managing logins to control who gets to post where. Drupal. My recommendation was we imitate Python.org a lot more by setting up mailman listservs with varying degrees of visibility to the public (some are members only and so on). I set up a Google Group by was of demonstration and ran it for a couple years. It's still out there. The advantage of mail-lists are not only are they searchable but they maintain the context and threads of conversation, great for organizational memory. However, for historical reason, our clerks prefer to use conference calls in real time, with someone taking minutes for the archives. A lose a lot that way. There's lots more listserv use since my tenure ended, by various interest groups, but no centralized place at the regional level for these listservs to go, which is probably just fine (we're pretty informal), however I never did find how I could get mailman servers installed at our ISP, back when I was filing reports and proposals. Our ISP only offered ancient majordomo as a listserv option, with precious little information on how to set one up. How does one set up a bunch of domain-name specific mail servers ala Python's mm3, is that in the ballpark of what you're asking? Kirby
Mailman list admin resources, scope clarification Here are the mailman 3 docs: http://docs.mailman3.org/en/latest/ IDK how much of the mailman 2 docs still apply? https://www.gnu.org/software/mailman/docs.html Here's the first result for search("docker mailman") https://github.com/maxking/docker-mailman And here are the "Mailman Suite Installation" > "Mailman 3 in Docker" docs: http://docs.mailman3.org/en/latest/prodsetup.html#mailman-3-in-docker TBH, securing and upgrading mailing lists is beyond the competencies of most volunteer-run organizations; which is one reason that I'd recommend Google Groups or similar for most organisations. In my experience, ISPs offer GUI installers for various app on shared hosting platforms, but upgrades aren't managed in the same GUI; which requires a volunteer to keep the apps upgraded with at least security updates. A VPS and/or container hosting doesn't make upgrading a one-click process; but sets the bar to where the list admin needs to be competent with SSH and ideally a configuration management system so that when they hand off admin responsibilities that organizational knowledge is preserved. Docker containers are often not secure by default; but can be extended FROM with commands in the Dockerfile, a shell script, or a configuration management tool which can apply a secure policy baseline. I haven't reviewed any of the containers linked here. Moreso interested to learn of new resources which teach how to contribute to an existing mailing list. Google Groups seems much easier for onboarding non-technical people without needing to forward everything. As an assumed public context, it may be fair to say that mailing lists elicit more helpful communications than non-archived email. On Thursday, August 30, 2018, kirby urner <kirby.urner@gmail.com> wrote:
But where does it teach me TO mailing list? I think that's the real question here.
Just to clarify what you're asking, here's a use case:
I was a volunteer Clerk of IT for a religious group that conducts business on-line but mostly by stowing information at a website, with all the headaches of managing logins to control who gets to post where. Drupal.
My recommendation was we imitate Python.org a lot more by setting up mailman listservs with varying degrees of visibility to the public (some are members only and so on). I set up a Google Group by was of demonstration and ran it for a couple years. It's still out there.
The advantage of mail-lists are not only are they searchable but they maintain the context and threads of conversation, great for organizational memory. However, for historical reason, our clerks prefer to use conference calls in real time, with someone taking minutes for the archives. A lose a lot that way.
There's lots more listserv use since my tenure ended, by various interest groups, but no centralized place at the regional level for these listservs to go, which is probably just fine (we're pretty informal), however I never did find how I could get mailman servers installed at our ISP, back when I was filing reports and proposals.
Our ISP only offered ancient majordomo as a listserv option, with precious little information on how to set one up.
How does one set up a bunch of domain-name specific mail servers ala Python's mm3, is that in the ballpark of what you're asking?
Kirby
I wanted to followup on this thread as since Aug 30 I've linked to it from several places. I've long had a habit of taking advantage what a publicly archived listserv permits: http linking from elsewhere. There's a link to a Python repo in the end notes. Otherwise I'm mostly just fleshing out a use case vis-a-vis mailman, confirming insights by Wes. On Thu, Aug 30, 2018 at 3:16 PM Wes Turner <wes.turner@gmail.com> wrote: ...
TBH, securing and upgrading mailing lists is beyond the competencies of most volunteer-run organizations; which is one reason that I'd recommend Google Groups or similar for most organisations.
Indeed, my experiences matches. The science fiction fantasy I was pursuing at the time, in my role, was that my religious sect in particular (for which I was wearing an IT hat) would eventually embrace IT expertise as one of its trademarks, a kind of branding maneuver. So sects are known for their chocolates and cheese. We'd stand out for our IT expertise. I was challenging my peers to "geek out" as we say. Some rose to the occasion. I wasn't the only IT type on the listserv (one of Google's). BTW I haven't given up on any of that investment in a higher tech look and feel, even though my personal tour of duty in that specific role ended quite a long time ago. That gig, as a Clerk of IT for my region, was a growth experience. I also continue fantasize about future meeting facilities in a high rise (as in "skyscraper"), for example some 47th floor facility in Singapore would be no contradiction in terms, not a culture clash. I picture a serene scene, perhaps with LCDs in the social area, sometimes cycling through pictures of those more iconic meetinghouses of the hallmark sort, many of them wood-heated and by this time fairly dilapidated.[1]
In my experience, ISPs offer GUI installers for various app on shared hosting platforms, but upgrades aren't managed in the same GUI; which requires a volunteer to keep the apps upgraded with at least security updates.
Exactly right. I'm on Godaddy myself and find Wordpress nags me and upgrades in place through its own GUI, but that's the exception, and is ironically the most infested with stuff. I had to SSH in and manually vim stuff out and vacuum tons of garbage directories -- I've not been a great janitor over the years (this was grunch.net). The website had essays and links I'd never put there, mostly tucked away unobtrusively so as not to attract my attention. Other upgrades, outside of Wordpress would require that I SSH in. At NPYM, we had no shell access that I recall, but my memory dims. To this day we make intensive use of Drupal -- but the security patch process was hardly intuitive (I wasn't handling it myself). Our PHP was falling behind, version-wise. In other words, we already had an inhouse-written and maintained PHP + MySQL database. Geeks R Us. I was able to test run SQL from a command line, thanks to help from Marty, and was suggesting we migrate these skills through the Secretary's office. Those proposals remain on file. I wrote a new prototype of our database in Python.[2] Kirby [1] https://youtu.be/PhsvqbCIaAs (opening 5 seconds show iconic meetinghouse, the rest being a music video recording of religious doctrines) [2] https://github.com/4dsolutions/NPYM
If you have SSH, it's generally possible to install git if it's not already, and then add everything to a git repository; keeping in mind that - like etckeeper - there are likely e.g. database passwords in said repository. A little extra CPU utilization during an off-peak time shouldn't be an issue even with shared hosting accounts. While I started out with e.g. postnuke, Mambo/Joomla, Drupal, etc. way back in the day; in recent times I've found myself leaning toward no database to maintain (no risk of SQLi). Static HTML and pull requests have most of the workflow needs solved without any ongoing maintenance burden. There are a number of comment services that handle spam and support moderation. A third party search service can do search with snippets that's way more performant. In my experience, PHP apps really do need to be regularly upgraded. https://www.staticgen.com lists quite a few static HTML solutions. Notably, Jekyll is the most popular and is supported by GitHub. It's also possible to build a dynamic app - where e.g. /admin/ is only available or known to a few users - that's then pressed into static HTML. Cactus (Django), Django-distill, and Frozen-Flask have a bunch of stars according to staticgen Such a static site is not quite the same as adding caching in front of e.g. WordPress because there's still SQL and unreviewed plugins. A managed WordPress service should be able to get caching correctly configured with e.g. Varnish, Nginx, HAproxy; and do regular backups. ... mm3 supports adding a footer with a link to the relayed message. distutils-sig@ has such a - IMHO far to extensive - footer The list admin should be able to upgrade edu-sig@ to mm3 in a jiffy? On Monday, September 24, 2018, kirby urner <kirby.urner@gmail.com> wrote:
I wanted to followup on this thread as since Aug 30 I've linked to it from several places.
I've long had a habit of taking advantage what a publicly archived listserv permits: http linking from elsewhere. There's a link to a Python repo in the end notes.
Otherwise I'm mostly just fleshing out a use case vis-a-vis mailman, confirming insights by Wes.
On Thu, Aug 30, 2018 at 3:16 PM Wes Turner <wes.turner@gmail.com> wrote:
...
TBH, securing and upgrading mailing lists is beyond the competencies of most volunteer-run organizations; which is one reason that I'd recommend Google Groups or similar for most organisations.
Indeed, my experiences matches.
The science fiction fantasy I was pursuing at the time, in my role, was that my religious sect in particular (for which I was wearing an IT hat) would eventually embrace IT expertise as one of its trademarks, a kind of branding maneuver. So sects are known for their chocolates and cheese. We'd stand out for our IT expertise.
I was challenging my peers to "geek out" as we say. Some rose to the occasion. I wasn't the only IT type on the listserv (one of Google's).
BTW I haven't given up on any of that investment in a higher tech look and feel, even though my personal tour of duty in that specific role ended quite a long time ago. That gig, as a Clerk of IT for my region, was a growth experience.
I also continue fantasize about future meeting facilities in a high rise (as in "skyscraper"), for example some 47th floor facility in Singapore would be no contradiction in terms, not a culture clash. I picture a serene scene, perhaps with LCDs in the social area, sometimes cycling through pictures of those more iconic meetinghouses of the hallmark sort, many of them wood-heated and by this time fairly dilapidated.[1]
In my experience, ISPs offer GUI installers for various app on shared hosting platforms, but upgrades aren't managed in the same GUI; which requires a volunteer to keep the apps upgraded with at least security updates.
Exactly right.
I'm on Godaddy myself and find Wordpress nags me and upgrades in place through its own GUI, but that's the exception, and is ironically the most infested with stuff.
I had to SSH in and manually vim stuff out and vacuum tons of garbage directories -- I've not been a great janitor over the years (this was grunch.net). The website had essays and links I'd never put there, mostly tucked away unobtrusively so as not to attract my attention.
Other upgrades, outside of Wordpress would require that I SSH in. At NPYM, we had no shell access that I recall, but my memory dims.
To this day we make intensive use of Drupal -- but the security patch process was hardly intuitive (I wasn't handling it myself).
Our PHP was falling behind, version-wise.
In other words, we already had an inhouse-written and maintained PHP + MySQL database. Geeks R Us.
I was able to test run SQL from a command line, thanks to help from Marty, and was suggesting we migrate these skills through the Secretary's office. Those proposals remain on file. I wrote a new prototype of our database in Python.[2]
Kirby [1] https://youtu.be/PhsvqbCIaAs (opening 5 seconds show iconic meetinghouse, the rest being a music video recording of religious doctrines)
participants (2)
-
kirby urner -
Wes Turner