NetBSD Developer Documentation: Information about the www mailing list
Responding to www@NetBSD.org mail
- What is involved in being a member of the www-rotation?
- Who can reply to www@NetBSD.org mail?
- Are there special requirements for the form of the replies?
- Any other rules about the messages other than content?
- I saw a mistake in a reply.
- How do we know when we are on call?
- Do I answer all mail when I am on call?
- Should I respond to mail on other lists?
- Are there any other tasks for the on call person?
- Where can I find the archives for this list?
- How do I join the www rotation?
Miscellaneous Notes
- Commonly used acronyms (rfv, l-o)
- Dealing with "I/O error: Attempt to load network entity"
- Online manual pages
Responding to www@NetBSD.org mail
What is involved in being a member of the www-rotation?
It involves covering one week every five or so. Tasks include
- Answering user questions to
<www@NetBSD.org>
and (to a lesser extent)<netbsd-users@NetBSD.org>
, including directing users to an appropriate list, or forwarding information onto specific developers. - Entering news items.
- Updating FAQs.
- Minor htdocs fixes.
You can certainly get by with less than an hour a day, though everyone is always encouraged to add more faq/news/information to the site...
Who can reply to <www@NetBSD.org>
mail?
Mail to <www@NetBSD.org>
is handled by a
team appointed for the purpose. Each member of the team is
given one week in a rotation during which they have the
primary responsibility for responding to the mail.
To do this they need to be subscribed to the www mailing list.
This list is not advertised on the public pages but you can
subscribe by going to
http://www.NetBSD.org/cgi-bin/subscribe_list.pl?list=www.
While the team has the primary responsibility for handling the www email, others are free to help out if they see a message that they think they are better suited to answer but they should first clear it with the on-call person. The purpose of this rule is simply to make sure that conflicting information is not sent to the correspondent. If a message is outstanding for a while, its probably OK to answer (the person on call could be busy) but still pop them a quick note that you are going to be handling it.
Are there special requirements for the form of the replies?
While there is no rule about specific format, messages should be clear, polite and in good taste. In particular, do not denigrate other operating systems. Review your messages for spelling and grammar. Generally try to direct correspondents to specific web pages or point them to our mailing lists for followup questions.
Any other rules about the messages other than content?
Each message should be copied to
<www@NetBSD.org>
and replies must be set to that
address as well. This just makes sure that everyone on the team
can review the messages not only to catch any mistakes that
may be made but also to help others formulate similar answers
when it is their turn in the rotation.
Also, try to respond to each message within approximately 24 hours (if possible). A quick response goes a long way to showing our users that we care about their feedback and is always appreciated.
I saw a mistake in a reply.
If you see that someone made a mistake in their reply, do not respond to the correspondent. Reply to the list explaining what you think should have been said and let the original responder correct himself or herself.
How do we know when we are on call?
Basically, there is a rotating "on call" shift. Each Tuesday morning a message is sent to the list describing who is coming on, who just came off and who's on next. The person coming on then responds to the list acknowledging that they are on. Any message from the time that ack hits the list to the same event the following week are the responsibility of that person. In order to clearly demark the changeover it is important to note that you are responsible from the time you see your acknowledgement come back, not from when you send it.
Do I answer all mail when I am on call?
No. Mail concerning the mail-index server index,
projects database and hardware database are answered
directly by Tim Rightnour <root@garbled.net>
so
there is no need to respond to those.
Should I respond to mail on other lists?
All members of the team are encouraged to respond to
mail on other NetBSD mailing lists, especially the help
list, but while the on call person is particularly
encouraged to make sure that questions don't go unanswered,
it is not as formal as the www list. Since
<www@NetBSD.org>
is given as a contact address
to the public, we try to give the feeling of dealing with a
single individual there but other lists are seen as general
discussion lists.
In addition, the members of the www list are also
responsible for answering <mirrors@NetBSD.org>
.
The instructions here mostly apply after substituting
'mirrors' for 'www' and there are further instructions here.
Are there any other tasks for the on call person?
The on call person should be taking primary responsibility for updating the site based on messages received on their shift. All team members should feel free to update the site where they see changes needed. The www list can be used to discuss any proposed changes if it is felt that discussion is necessary.
Where can I find the archives for this list?
This list is archived on mail.NetBSD.org in the directory
/mail/archive/www
. The current email is
in .current
. The rest in gzipped files.
Be aware that these archives are not cleaned for spam so there
is a lot of garbage in them.
How do I join the www rotation?
To add or remove yourself from the rotation simply modify the file htutils/scripts/rotate/list and commit your change. Just follow the format of the other entries in that file.
Miscellaneous Notes
Commonly used acronyms (rfv, l-o)
There are a couple of commonly used acronyms one will see on the www mailing list.
- rfv: request for volunteers - The acronym rfv is used in the Subject: line of messages containing content that should be added to the NetBSD web site. They usually are FAQ and News items that should be touched up and committed to htdocs.
- l-o: list-only - The acronym l-o is used in the Subject: line of three types of messages. The first is when the on-call person wants to ask a question to the www list, regarding a piece of www mail, before responding to the sender. The second is when a person who's not on call has something to say about a piece of external www mail. The third is when someone notices a mistake in a reply that's gone out. The acronym l-o:, prefixed to the original subject, helps to differentiate what messages have had a response to the sender and which haven't.
Dealing with "I/O error: Attempt to load network entity"
Every now and then, people trying to (re)build htdocs get errors like:
[xsltproc] layout.xml -> autolayout.xml I/O error : Attempt to load network entity http://docbook.sourceforge.net/release/website/2.6.0/xsl/autolayout.xsl warning: failed to load external entity "http://docbook.sourceforge.net/release/website/2.6.0/xsl/autolayout.xsl" compilation error: file /src/NetBSD-current/htdocs/./share/xsl/autolayout.xsl line 9 element import xsl:import : unable to load http://docbook.sourceforge.net/release/website/2.6.0/xsl/autolayout.xsl *** Error code 5
The problem lies within the XML based toolchain which tries to load a number of "catalog" files, and fails as it cannot find some configuration file.
The cause for this may be that either the "catalog" files
are messed up, or because the XML toolchain can't find its
configuration file. A common cause for the latter is setting
PKG_SYSCONFBASE
conditionally on
BSD_PKG_MK
being defined in
/etc/mk.conf
—htdocs doesn't define the
latter. The cleanest way to get it working is:
# note the addition of BUILDING_HTDOCS here. .if defined(BSD_PKG_MK) || defined(BUILDING_HTDOCS) ... PKG_SYSCONFBASE= ... ... .endif
Online manual pages
Manual pages can be referenced using an XML entity, for
example: &man.cat.1;
which results in
cat(1). They are all defined at
htdocs/share/xml/man-refs.ent
. The
manual pages are hosted online at //man.NetBSD.org/. To add a new
manual page, add it to the man-refs.ent
file and also email Kimmo Suominen about the new page if it doesn't exist
on that webserver.
Back to Developer Documentation