There are 2 different way to approach this topic, the technical part of mailing lists and the behavioral aspect of it. I’ll quickly go through the first one.
A mailing list is a mechanism where a lot of email address resource to a list address to replicate the message throughout the subscribers. It can be delivered in two modes, as single email (the preferred one) as summary which compile emails from the week or month into one single email.
To join a mailing list, there are two possible process, through the list website, or through email process. The second one is usually the more common, and the exercise go like the following:
- Send an email o the list suffixing ‘-subscribe‘ to the recipient. No subject or content necessary.
ex. email@example.com where ‘mylist’ is the recipient
- Expect a reply from the list asking for verification, the content of the email have a URL which you can click to verify
- Alternatively you can reply back to the received email.
- Expect a confirmation-welcome email.
- Send your first email to the list to the list address firstname.lastname@example.org
Now the behavioral part
Of course your motives to joining the list might vary, if you are looking for help, you might got to a list aimed at users or support. While if you want to contribute, you might look for dev which will focus on development, larger projects might have some qa for quality assurance.
So first lesson is understanding what information might be useful, again this depends on your porpoise and type of list you are on. But as a general rule, try to: focus on the information relevant to the reader, not to you.
In other words, avoid giving irrelevant information, although you might think that giving more information is better, too much information could make the reader hard to get to the point. So, avoid the spam-ish info. Information like your system specs could be valuable, make sure you show the issue first and compliment the main information with more details.
Second lesson is try to participate, voting, call for help, call for support, documentation, and other areas could be great first contributions to the community. More than asking where to start (although nothing wrong with this), try reviewing the project wiki, or documentation which will probably have you covered. Instead try to ask something along the lines of that information, or even better, comment on your first contribution to get some feedback on it.
Reviewing the DSCM (like git, svn) comments could become a great way to review code, provide patches, and get involved with cleaning up code. From comments on the class, function or modules, to refactoring (depending on your skill) and optimization.
If you think your skills or the code tree is too much to understand it. Make sure you can focus instead on the final product. Downloading and compiling (or installing) could provide good testing reports on ‘so called’ squashed bugs. Copy your comments to the list (QA or dev). This will only need power users (for compiling) or regular users (for regular install) and provide your own feedback.
A list might flood your inbox, so using filters/labels might be good to keep the traffic off your regular email. Reading emails even if they are not target to you is in general a good practice. Even if you don’t completely get it, it will help you understand what’s going on with the community. To accelerate these process, you can review the archives.
Scanning through months of conversations can quickly open your eyes with the way the community behaves, evolves and where is going to. Usually go to the signature of any email to go to the site of the list, like: domain.org/cgi-bin/mailman/listinfo/flisol
You would be able to identify the “About” section with the line: To see the collection of prior postings to the list, visit the (mylist) Archieve
A table containing months, type of order by: thread, topic, date and author. This will make you easily read the list, even if it might not be the best to search through it.