Quoting Valerie Dow (vdow@unex.berkeley.edu):
I'm fairly new to UC Berkeley Extension. We have a cluster of intensive Linux short courses that start this month. Is it appropriate for me to post an announcement about the courses on the BALUG-TALK list? I've attached a press release. Let me know if it's possible to announce these courses to BALUG and the best way to do so.
Oh, I think that would be fine. I'm cc'ing the balug-admin mailing list to solicit other comments if any.
Please strongly consider copying and pasting the substantive contents of your MS-Word file inline into your posting's body text -- or in some other way post real ASCII -- as opposed to file-attaching an MS-Word document to the mailing list. Posting binary-format attachments to mailing lists is, in general, a bad idea.
(If my point is unclear, please say so, and I'll be glad to clarify.)
In fact, I've just run the press release through a filter that extracts plaintext from MS-Word files, so here y'are:
UC Berkeley Extension Announces Embedded Linux Short Courses
January 7, 2009, Berkeley CA
UC Berkeley Extension announces four new intensive embedded Linux courses in its spring line up starting January 26 in Redwood City taught by Dr. Kevin Dankwardt, an author, speaker, and instructor who has specialized in embedded Linux for the last 10 years.
"Unlike most of our other courses," says UC Extension Program Director Jim Connor, "these are short, intensive courses lasting one to five consecutive days that are designed to provide software developers with a very efficient, accelerated learning experience." The courses are very hands-on with a wealth of practical exercises so a developer or an entire team could take all four of these courses in January and early February", says Connor, "and have a rapid ramp up working with embedded Linux."
The short courses, held in Redwood City, are:
Linux Application Program Design and Development
January 26-30, 8 am - 3 pm
EDP 326223
Linux Device Driver Issues Design and Development
January 26-30, 3 pm - 10 pm
EDP 326321
Real-time Linux Design Development and Measurement
January 31, 8 am - 6 pm
EDP 326249
Embedded Linux Design and Development
February 2-4, 8 am - 7 pm
EDP 326215
Students should have some experience with UNIX/Linux fundamentals and C. "These four short courses complement each other, says Extension's Jim Connor. "Developers who work at the application level or kernel level will benefit greatly from each of them. We're very excited to have these short courses as part of our program this spring," says Connor.
Dr. Dankwardt earned his Ph.D. in Computer Science from The Center For Advanced Computer Studies at the University of Louisiana (Lafayette), and held a professorship at Louisiana Tech University where he served as Chairman of the Computer Science Department. Additionally, he chairs the Education committee of the Embedded Linux consortium, and serves as contributing Editor to LinuxDevices.com.
Founded in 1891, UC Berkeley Extension, [1]www.unex.berkeley.edu, is the continuing education branch of the University of California Berkeley. Today, Extension offers 1,500 courses each year, including online courses, along with more than 30 certificate and professional programs.
To find out more about these Linux courses and other open source courses offered at UC Berkeley Extension this term, visit [2]http://www.unex.berkeley.edu/cat/cis.html#openos or call 510.642.4150. To find out about the computer technology and information management program at UC Berkeley Extension, visit [3]www.unex.berkeley.edu/it.
# # # #
References
1. http://www.unex.berkeley.edu/ 2. http://www.unex.berkeley.edu/cat/cis.html#openos 3. http://www.unex.berkeley.edu/it
announcing the classes seems like a good idea to me. i agree with rick: no binaries, no attachments in email to groups. use ASCII inline as a courtesy to readers (and administrators). note i've tried to improve readability in the items below (got rid of newlines within blocks).
On Wed, 2009-01-07 at 13:42 -0800, Rick Moen wrote:
Quoting Valerie Dow (vdow@unex.berkeley.edu):
I'm fairly new to UC Berkeley Extension. We have a cluster of intensive Linux short courses that start this month. Is it appropriate for me to post an announcement about the courses on the BALUG-TALK list? I've attached a press release. Let me know if it's possible to announce these courses to BALUG and the best way to do so.
Oh, I think that would be fine. I'm cc'ing the balug-admin mailing list to solicit other comments if any.
Please strongly consider copying and pasting the substantive contents of your MS-Word file inline into your posting's body text -- or in some other way post real ASCII -- as opposed to file-attaching an MS-Word document to the mailing list. Posting binary-format attachments to mailing lists is, in general, a bad idea.
(If my point is unclear, please say so, and I'll be glad to clarify.)
In fact, I've just run the press release through a filter that extracts plaintext from MS-Word files, so here y'are:
UC Berkeley Extension Announces Embedded Linux Short Courses
January 7, 2009, Berkeley CA
UC Berkeley Extension announces four new intensive embedded Linux courses in its spring line up starting January 26 in Redwood City taught by Dr. Kevin Dankwardt, an author, speaker, and instructor who has specialized in embedded Linux for the last 10 years.
"Unlike most of our other courses," says UC Extension Program Director Jim Connor, "these are short, intensive courses lasting one to five consecutive days that are designed to provide software developers with a very efficient, accelerated learning experience." The courses are very hands-on with a wealth of practical exercises so a developer or an entire team could take all four of these courses in January and early February", says Connor, "and have a rapid ramp up working with embedded Linux."
The short courses, held in Redwood City, are:
Linux Application Program Design and Development January 26-30, 8 am - 3 pm EDP 326223
Linux Device Driver Issues Design and Development January 26-30, 3 pm - 10 pm EDP 326321
Real-time Linux Design Development and Measurement January 31, 8 am - 6 pm EDP 326249
Embedded Linux Design and Development February 2-4, 8 am - 7 pm EDP 326215
Students should have some experience with UNIX/Linux fundamentals and C. "These four short courses complement each other, says Extension's Jim Connor. "Developers who work at the application level or kernel level will benefit greatly from each of them. We're very excited to have these short courses as part of our program this spring," says Connor.
Dr. Dankwardt earned his Ph.D. in Computer Science from The Center For Advanced Computer Studies at the University of Louisiana (Lafayette), and held a professorship at Louisiana Tech University where he served as Chairman of the Computer Science Department. Additionally, he chairs the Education committee of the Embedded Linux consortium, and serves as contributing Editor to LinuxDevices.com.
Founded in 1891, UC Berkeley Extension, [1]www.unex.berkeley.edu, is the continuing education branch of the University of California Berkeley. Today, Extension offers 1,500 courses each year, including online courses, along with more than 30 certificate and professional programs.
To find out more about these Linux courses and other open source courses offered at UC Berkeley Extension this term, visit [2]http://www.unex.berkeley.edu/cat/cis.html#openos or call 510.642.4150. To find out about the computer technology and information management program at UC Berkeley Extension, visit [3]www.unex.berkeley.edu/it.
# # # #
References
- http://www.unex.berkeley.edu/
- http://www.unex.berkeley.edu/cat/cis.html#openos
- http://www.unex.berkeley.edu/it
BALUG-Admin mailing list BALUG-Admin@lists.balug.org http://lists.balug.org/listinfo.cgi/balug-admin-balug.org
Quoting jim (jim@well.com):
announcing the classes seems like a good idea to me. i agree with rick: no binaries, no attachments in email to groups. use ASCII inline as a courtesy to readers (and administrators).
note i've tried to improve readability in the items below (got rid of newlines within blocks).
Ah, you see, that's a rare case of (minor) dissent. I'm old-school, and think it's really rather rude to post lines greater than 80 columns to (most) mailing lists, absent exceptional reasons such as long lines of code that should not be split.
You'll notice that I deliberately keep what I post (except for .signature blocks, which by design are 4x80 columns, and notionally not part of the message text) within the first 75 columns of screen width, using hard returns to ensure that -- and also rewrap quoted text as required to fully comply with that community standard.
"Getting rid of newlines within blocks" is, by that standard, doing precisely The Wrong Thing, and going out of your way to do so.
Rick,
You've emailed/posted/etc. many many times about how to, and how not to post to lists, etc. (e.g. plain text, don't do attachments, etc.) ... and we thank you very much for that! :-) ...
To hopefully be a bit more proactive, do you have recommended web page(s) (most any suitable URL will do - but probably best if it's a web page or the like that at least somebody somewhere can tweak/update as/when suitable, rather than a read-only archived message that's web accessible) somewhere on that topic (if not, we could potentially create one, if we wanted).
Anyway, I was thinking, adding a few brief mentions about such on our list pages (the ones with the policy stuff, etc.), and linking to such, might help folks better use the lists to start with, and have fewer questions/issues to be emailed/posted about, etc. (and also keep us from tossing too much text onto those list policy pages themselves).
Let us know.
Thanks.
maybe add judicious links to rick's pages?
On Sat, 2009-01-10 at 10:52 -0800, Michael Paoli wrote:
Rick,
You've emailed/posted/etc. many many times about how to, and how not to post to lists, etc. (e.g. plain text, don't do attachments, etc.) ... and we thank you very much for that! :-) ...
To hopefully be a bit more proactive, do you have recommended web page(s) (most any suitable URL will do - but probably best if it's a web page or the like that at least somebody somewhere can tweak/update as/when suitable, rather than a read-only archived message that's web accessible) somewhere on that topic (if not, we could potentially create one, if we wanted).
Anyway, I was thinking, adding a few brief mentions about such on our list pages (the ones with the policy stuff, etc.), and linking to such, might help folks better use the lists to start with, and have fewer questions/issues to be emailed/posted about, etc. (and also keep us from tossing too much text onto those list policy pages themselves).
Let us know.
Thanks.
BALUG-Admin mailing list BALUG-Admin@lists.balug.org http://lists.balug.org/listinfo.cgi/balug-admin-balug.org
Certainly among (if not top-most) of what I had in mind ... but being lazy (efficient ;-)) I thought Rick might handily provide recommended URL(s).
Quoting jim jim@well.com:
maybe add judicious links to rick's pages?
On Sat, 2009-01-10 at 10:52 -0800, Michael Paoli wrote:
Rick,
You've emailed/posted/etc. many many times about how to, and how not to post to lists, etc. (e.g. plain text, don't do attachments, etc.) ... and we thank you very much for that! :-) ...
To hopefully be a bit more proactive, do you have recommended web page(s) (most any suitable URL will do - but probably best if it's a web page or the like that at least somebody somewhere can tweak/update as/when suitable, rather than a read-only archived message that's web accessible) somewhere on that topic (if not, we could potentially create one, if we wanted).
Anyway, I was thinking, adding a few brief mentions about such on our list pages (the ones with the policy stuff, etc.), and linking to such, might help folks better use the lists to start with, and have fewer questions/issues to be emailed/posted about, etc. (and also keep us from tossing too much text onto those list policy pages themselves).
Let us know.
Thanks.
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
You've emailed/posted/etc. many many times about how to, and how not to post to lists, etc. (e.g. plain text, don't do attachments, etc.) ... and we thank you very much for that! :-) ...
To hopefully be a bit more proactive, do you have recommended web page(s) (most any suitable URL will do - but probably best if it's a web page or the like that at least somebody somewhere can tweak/update as/when suitable, rather than a read-only archived message that's web accessible) somewhere on that topic (if not, we could potentially create one, if we wanted).
There are a number of subtle points on this, relating to mailing list social dynamics and user psychology. I started to write a response to you on this, a few days ago: I abandoned the draft as too long and complex, sorry.
Most mailing list policy and netiquette suggestions pages (and please note that those are not the same) are hopelessly verbose messes, and fail to achieve their aims. Here's an example of what to avoid -- the set of SVLUG pages that metastasised during my several-year absence from the SVLUG Web Team:
http://web.archive.org/web/20030412175517/www.svlug.org/policies/list-policy... http://web.archive.org/web/20030422073501/www.svlug.org/maillists/index.shtm... http://web.archive.org/web/20030422074441/www.svlug.org/policies/job-policy.... (Plus individual lists' listinfo pages.)
There are a number of gotchas[0], some revolving around the people who most need to benefit from such suggestions being least likely to read, comprehend, and act on them. I'm going to skip those topics, as being too long a discussion.
My strong preference in mailing list policy is:
1. Make policy self-enforcing to the extent possible, leveraging automation. E.g., many people who post attachments will exceed Mailman's per-post size limit, resulting in the mail being held for moderator attention, at which point you reject it and say "please don't file-attach huge MS-Word files or for that matter any non-plaintext other than possibly GnuPG/PGP/etc. signatures".
As another example, people who Bcc mailing lists -- another bad habit -- will likewise get their posts held (as above).
Likewise, people who madly crosspost, another obnoxious habit, will tend to hit the "too many recipients" filter, with similar outcomes[1].
2. What works best is an extremely terse list of the 2-3 things posters are most likely to do wrong, that you most care about deterring, documented on the listinfo page. Like this:
http://linuxmafia.com/mailman/listinfo/conspire
Having inherited an unholy mess at SVLUG, I've shrunk the number and size of pages about policy, and altered the main page to make clear that listadmins will intervene only to "halt spam" and to "halt major interruptions of online spew".
http://www.svlug.org/policies/list-policy.php
[0] Listadmins encounter vast outbreaks of "tactical stupidity", when posters profess to have forgotten or not understood what they find inconvenient. E.g., I had cured SVLUG's biggest behaviour problem remaining after its alcoholic president's resignation, by interpreting the prohibition against "offtopic spew" as requiring that organisational topics be confined to the Volunteers list, a number of people kept deliberately claiming to not understand (Einfeldt, Cherlin, others). Even sincere posters will tend not to see such pages in a timely manner.
There is also the unfortunate perception that listadmins are obliged to document everything people should not do, and that anything not so documented is OK -- which is of course rubbish: In general, it's pretty obvious what not to do, and there's really no point in trying to list everything.
See also: http://linuxmafia.com/~rick/lexicon.html#moenslaw-documentation
[1] Quite a number of people persisted in deliberately disregarding my polite requests (as listadmin) that they not cross-post between svlug@lists.svlug.org and elsewhere. After getting tired of waiting for people to behave sensibly voluntarily, I finally put in a couple of Mailman filters to autoreject the most-common cross-posts -- and, magically, the offenders ceased even to try.
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
You've emailed/posted/etc. many many times about how to, and how not to post to lists, etc. (e.g. plain text, don't do attachments, etc.) ... and we thank you very much for that! :-) ...
To hopefully be a bit more proactive, do you have recommended web page(s) (most any suitable URL will do - but probably best if it's a web page or the like that at least somebody somewhere can tweak/update as/when suitable, rather than a read-only archived message that's web accessible) somewhere on that topic (if not, we could potentially create one, if we wanted).
Let me take another swing at this one, and my apologies for having been rushed. (I'll still be rushed, but have some thoughts I'd like to articulate, from a slightly different angle.)
There are indeed pages out there that give tips about how to best participate on mailing lists as to posting style, things to do and not do, etc., especially as a newcomer to the online technical community. I can hunt them down and cite them -- but so can you. ;->
The thing is, most of the time those don't work very well, and, if you think about it from the viewpoint of _process_ (sequence of events), the reasons for this (general) failure become evident -- especially when one's primary aim is to reduce the incidence of misbehaviour. One is that someone about to post essentially never stops to think "Oh, maybe I should stop before posting and go read this group's tips on how to participate first, so I don't mess up."
There's a necessary distinction between lists of tips and lists of allegedly enforced mailing list rules -- but neither of them tends to work well (in the above-described sense). The people who would most benefit from them, i.e., those who genuinely don't know how to post cluefully and why, are least likely to read them (especially in advance).
And then there are those who _do_ know better: These will often ignore any posted rules or guidelines entirely, and if challenged will cite nonsensical, invented-after-the-fact reasons why they're supposedly an exception -- or a corner case that they'll assert that you haven't covered. (Computerists tend to madly adore babbling about alleged corner cases.) A large fraction of computer geeks think that if something is posted somewhere, and expresses a point of view, that implies that the matter's up for debate. The more you write on the subject, and the greater the detail you expound, the more they assume it really is up for debate.
You couldn't possibly be serious, they think, if you're that verbose. They're trained to think that a big, red sign saying only "STOP" is probably serious, while one saying "Stop, except of course as required for safety, e.g., to get out of the way to avoid collision, and in certain other cases" isn't serious at all. That's human nature. That's how _real_ people think, which is just not the way computerists assume they do.
Moreover, most people in all populations operate from a tacit assumption that, if it's physically possible to do something, it must be OK -- that any rule worth respecting is enforced in a way that makes it the path of least resistance, and that any rule that can be ignored is just noise. Suggest to them that they should _not_ follow the path of least resistence just to do the right thing, and they'll want to know why they should do you a favour.(!)
(Consider the number of technical people on Linux mailing lists who post from GMail and who both top-post and quote entire prior message threads in every posting. Do you think it's because they don't know that's wrong and rude? No, they're almost uniformly fully aware of that. They just can't be bothered to do anything requiring extra effort.)
And then, a certain number of people will argue with anything: If you put up a page saying "Please don't post Lotus 1-2-3 spreadsheets", someone will figure out how to create one, and post it, just to push back. Or invent some alleged corner case, and do likewise.
A great many cultural-norm rules are present in automatically enforced form, by being embedded into the software. In many cases, those magically cease to be perceived as rules: They become perceived as merely the base reality to which subscribers accomodate themselves.
For example, Mailman has a built-in ceiling on individual message size, which by default is low enough that it snags almost all, e.g., MS-Word attachments, but high enough that all legitimate postings go through. Do we see a lot of angry postings protesting the listadmin's tyranny in cruelly rejecting Joe User's 40MB PowerPoint attachment? Nope. Joe gets the automatic reject notice, and thinks "Oh, I guess I can't do that." No debate then ever arises.
Back in Majordomo days, there was an incessant tussle with people who erroneously sent "Please unsubscribe me" postings to the broadcast addresses of mailing lists. They would screw up, get chewed out for being twits, protest the supposed purity of their motives as making it perfectly OK to be asshats in public, attempt to blackmail their way into having the listadmin figuratively wipe their noses for them (i.e., unsubscribe them anyway just to shut them up), and so on. Mailman put an end to about 99% of that through its automatic "administrivia" filter that intercepts most such posts and redirects them to the listadmin.
The crossposting is another case in point: People here may recall how I kept politely asking Kristian Erik Hermansen and several other people to please cease crossposting between svlug@lists.svlug.org and sf-lug@linuxmafia.com -- and his reaction was to scream listadmin oppression and keep doing it, keeping his roster of recipients down to a few, to avoid the "Too many recipients" filter. (People who responded to his posts, in contrast, often hit that filter, because they added one or two recipients in replying.)
I tried for many months to just ask people nicely, and the problem kept getting worse, and eventually just created a couple of filters to intercept and autoreject a couple of the most common crossposts between svlug@lists.svlug.org and elsewhere. And, immediately, no protest marches or namecalling about the mean listadmin, and no more attempts to crosspost after just one that got bounced: That's because it was now seen as built into the software, instead of being something in words, which is then seen as the user being asked to do someone a favour.
Now, I am _not_ suggesting hiding into the software various attempts to manipulate members of mailing lists. A smart listadmin seeks to cut to the absolutely bare minimum the amount of hassle that he/she and also list subscribers need to endure. A smart listadmin runs the mailing lists' unmoderated to the extent possible, and tries to automate everything that can be processed without his/her help. Less regimentation and control means less work, less friction, more pleasantness.
Continuing a point I saying a few days ago:
Moreover, most people in all populations operate from a tacit assumption that, if it's physically possible to do something, it must be OK -- that any rule worth respecting is enforced in a way that makes it the path of least resistance, and that any rule that can be ignored is just noise. Suggest to them that they should _not_ follow the path of least resistence just to do the right thing, and they'll want to know why they should do you a favour.(!)
(Consider the number of technical people on Linux mailing lists who post from GMail and who both top-post and quote entire prior message threads in every posting. Do you think it's because they don't know that's wrong and rude? No, they're almost uniformly fully aware of that. They just can't be bothered to do anything requiring extra effort.)
Part of what I was getting at is that it's neither necessary nor desirable to post rules (or even guidelines) forbidding every single little wrong thing people could do on a mailing list. I just now had an example: A Wikimedia Foundation guy in San Francisco just tried to post two job-offer ads to the SVLUG Jobs mailing list. I was obliged to politely reject them, with this message:
Eugene, I'm sorry to have to welcome you to this mailing list with bounces of your postings. In general, they're fine, i.e., they're within 75 miles of San Jose and are Unix/Linux-centric as required on http://lists.svlug.org/lists/listinfo/jobs . The problem lies in your bit about (paraphrased) "visit [URL]" to see details of the openings". No, can't do that. The moderators need to see the details of the job inline in your posting, so they can verify that it meets our guidelines. Please post again with the job descriptions pasted into your post. Thanks!
The mailing list's formal rules are here: http://lists.svlug.org/lists/listinfo/jobs
The ones that really matter are the first two:
# Posted jobs must be Unix- or Linux-centric (AIX, HP-UX, IRIX, Solaris, etc. all OK). Having Linux or Unix as a nice-to-have is not enough.
# Fulltime positions must be within a 75-mile radius of San Jose. No exceptions.
In order to verify that postings comply (especially with the first part), the Jobs moderator needs to see the jobs description. So, pragmatically speaking, it needs to be inline -- and merely including this sort of stuff doesn't qualify:
See the linked pages for details and how to submit your CV: http://wikimediafoundation.org/wiki/Job_openings/Interaction_Designer_(proje...) http://wikimediafoundation.org/wiki/Job_openings/Sr._Software_Developer_(pro...) http://wikimediafoundation.org/wiki/Job_openings/Software_Developer_(project)
Now, the formal rules at http://lists.svlug.org/lists/listinfo/jobs don't _say_ "Your posting must include the job description, not just a hyperlink to it." Do they need to? Is it unfair to bounce postings if that's not part of the formal rules?
No and no. The posted rules cannot possibly cover every possible way of violating the spirit of the rules. Some things need to be regarded as obvious, and left up to the poster to figure out. Otherwise:
o There's a perception that anything not forbidden is permitted. o The ruleset becomes a ridiculously complex mess, which o tends to get ignored because people assume you aren't serious, or that they're an exception.
If recruiters / managers were _frequently_ posting omitting job descriptions and asking people to visit [URL] for details, _then_ I might append something to the listinfo page.
To review, rules/guidelines are best kept really minimal and simple, for many reasons. And it's OK to omit coverage of rare and unlikely mishaps.