Next: Taking Advantage of Savannah, Previous: Peer Review, Up: Team Co-ordinators [Contents][Index]
As all team leaders have write access to the CVS repository of the ‘www’ project, this technically means that they are able to modify every single file in it. This vote of confidence should never be abused—the only files team co-ordinators should add/update are those relevant to their translation work. It is OK to fix an obvious typo in an original article; for anything else please report to webmasters@gnu.org.
If you wish to volunteer as webmaster and help with generic webmaster work and RT tickets, that is perfectly fine—please follow the established (by the GNU Webmasters) procedure. If you are approved, you can modify such pages wearing your “webmaster’s hat”.
If a particular page has issues with the markup which create problems for your language, please inform trans-coord-discuss@gnu.org. For general issues that affect more articles, or for severe problems, please write to www-discuss@gnu.org.
If you are not familiar with CVS, it is recommended to read CVS manual, for a basic understanding of how this VCS works. See Concurrent Versions System in Version Management with CVS. It is not necessary to become an expert—the ‘www’ project does not use complex features like tags, vendor branches, merging, etc. as they are not very useful for a live website.
However, you’d probably have to learn how to use CVS for effective work—to extract information from the history, review diffs and specific changes, synchronize with the working repository of the team (if any), adding/removing files, etc.
If you make changes that affect more than one file but the change is coherent, please do it as a single commit. This will generate only one message to www-commits@gnu.org, which is better than 5 messages for 5 files about semantically the same change. Always write commit logs in English3, providing a short description of the change. If you modify a file that is not an article but a script or part of software (such as server/gnun/gnun.mk), it would be nice to follow the GNU Coding Standards and describe the change precisely (see Change Logs in The GNU Coding Standards). For example, do not write:
Added support for Nepali.
or
Yay! First commit of the Panjabi homepage!
Instead, write the log as follows:
(TEMPLATE_LINGUAS): Add `ne'.
and
(FUZZY_DIFF_LINGUAS): Add `pa'.
This makes it easier for others to search for a particular change in the history.
If you add a binary file (for example, .png), do it with
cvs commit -kb file. This turns off keyword substitution,
which prevents RCS keywords like ‘$Id$’ to get expanded,
subsequently corrupting the file. See Substitution modes in Version Management with CVS. More importantly, using -kb
prevents corruption of the binary when people using CVS clients under
infamous OS checkout modify the file, and then commit it with
messed ends of lines.4
Although not absolutely compulsory, it is recommended that every team leader subscribes to www-commits@gnu.org. It is useful to examine the diffs of your own messages, if you miss something while inspecting the diff before the commit. In any case, a team leader should be subscribed to that list to avoid his own commit messages to be moderated. If you absolutely do not desire receiving all traffic, just disable mail delivery in Mailman’s user interface.
This advice is applicable for the ‘www’ repository only—feel free to write logs in your native language when committing in your team’s repositories.
Few years ago there still were committers using nonfree operating systems—we don’t dictate what OS people use, but we can at least prevent this technical kind of damage.
Next: Taking Advantage of Savannah, Previous: Peer Review, Up: Team Co-ordinators [Contents][Index]