[Savannah-cvs] [554] improve markup, add titles, update

[ineiev]

Revision: 554
          
http://svn.savannah.gnu.org/viewvc/?view=rev&root=administration&revision=554
Author:   ineiev
Date:     2023-02-07 04:34:31 -0500 (Tue, 07 Feb 2023)
Log Message:
-----------
improve markup, add titles, update

Modified Paths:
--------------
    trunk/sviki/AboutTranslations.mdwn
    trunk/sviki/ChangingLicense.mdwn
    trunk/sviki/DocumentationNotices.mdwn
    trunk/sviki/GnuGplTwoOrLater.mdwn
    trunk/sviki/HowKnowIfALicenseIsFreeIn3Points.mdwn
    trunk/sviki/MirroringExternalRepository.mdwn
    trunk/sviki/ModifyingGroupType.mdwn
    trunk/sviki/NonGnuToGnuSysadmin.mdwn
    trunk/sviki/SavannahCountryRestrictions.mdwn
    trunk/sviki/UpstreamCollaboration.mdwn
    trunk/sviki/WhyLegalChecksBeforeRelease.mdwn

Modified: trunk/sviki/AboutTranslations.mdwn
===================================================================
--- trunk/sviki/AboutTranslations.mdwn  2023-02-07 09:32:21 UTC (rev 553)
+++ trunk/sviki/AboutTranslations.mdwn  2023-02-07 09:34:31 UTC (rev 554)
@@ -1,7 +1,8 @@
-If a translation of an existing free software project wishes to be hosted
+# Hosting translations
+
+If a translation of existing free software wishes to be hosted
 at Savannah, check the following:
 
-* Why does the translation need to be separate from the rest of the project
-(= why can't it be hosted with the rest of the project)
-* Check if the translated project is under a GPL compatible license
-(any translation will fall under the parent project's license)
+* If the translation can be hosted with the rest of the package.
+* If the translated package is under a GPL-compatible license
+  (any translation should fall under the license of its software).

Modified: trunk/sviki/ChangingLicense.mdwn
===================================================================
--- trunk/sviki/ChangingLicense.mdwn    2023-02-07 09:32:21 UTC (rev 553)
+++ trunk/sviki/ChangingLicense.mdwn    2023-02-07 09:34:31 UTC (rev 554)
@@ -1,17 +1,17 @@
-Sometimes, a project wants to change to a different license than the
+# Changing license
+
+Sometimes, a group wants to change to a different license than the
 one used during the registration process.
 
-The "license" field in the project page can only be modified by
+The "license" field in the group page can only be modified by
 Savannah admins because the license must remain a free license.
 
-When a project wants to switch the license they contact us and we then
+When a group wants to switch the license they contact us and we then
 change it via the group administration pages.
 
 Log into Savannah.  Become superuser.  Select "Main page".  Select
-"Browse Groups List".  Search for the project name in the Group Search
-form.  A direct link is:
+"Browse Group List".  Search for the group name in the Group Search
+form.
 
-  https://savannah.nongnu.org/siteadmin/grouplist.php
-
 Change the license in the selection box then submit the form with the
 "Update" button.

Modified: trunk/sviki/DocumentationNotices.mdwn
===================================================================
--- trunk/sviki/DocumentationNotices.mdwn       2023-02-07 09:32:21 UTC (rev 
553)
+++ trunk/sviki/DocumentationNotices.mdwn       2023-02-07 09:34:31 UTC (rev 
554)
@@ -1,21 +1,24 @@
-Q: Where do you put the license and notice?
+# Documentation notices
 
-A: I'd recommend using the standard notice
-(<http://www.gnu.org/licenses/fdl.html#SEC4>),
-plus the GFDL full text included as a section of the documentation.
-Then, in each documentation source code, use the tiny license notice (+
-copyright notice) that can be found at
-<http://www.gnu.org/licenses/fdl-howto.html>
+<dl><dt>Where do you put the license and notice?</dt>
 
-To make it clearer: the standard copyright+license notice would appear
-in the resulting printed document, in the copyright page, near the
-beginning of the book; the GFDL is another section, usually at the end.
-The tiny notices would not appear in the resulting document, only in
-each file of the manual source code.
+<dd>
+<p>I'd recommend using the <a
+href="//www.gnu.org/licenses/fdl.html#SEC4"> standard notice</a>, plus
+the full text of the  GFDL included as a section of the documentation.
+Then, in each documentation source code, use the tiny license notice
+(+ copyright notice) that can be found in the <a
+href="//www.gnu.org/licenses/fdl-howto.html">FDL Howto</a>.</p>
 
-[[ToDo]]: I wonder how it's done exactly for elisp.texi
+<p>To make it clearer: the standard copyright and license notices
+would appear in the resulting printed document, in the copyright page,
+near the beginning of the book; the GFDL is another section, usually
+at the end.  The tiny notices would not appear in the resulting
+document, only in each file of the manual source code.</p>
+</dd>
 
-Q: But in the end, every "end-format" (pdf, html) must print out the
-whole license and one copyright line, right?
+<dt>But in the end, every "end-format" (pdf, html) must print out the
+whole license and one copyright line, right?</dt>
 
-A: Yes
+<dd><p>Yes.</p></dd>
+</dl>

Modified: trunk/sviki/GnuGplTwoOrLater.mdwn
===================================================================
--- trunk/sviki/GnuGplTwoOrLater.mdwn   2023-02-07 09:32:21 UTC (rev 553)
+++ trunk/sviki/GnuGplTwoOrLater.mdwn   2023-02-07 09:34:31 UTC (rev 554)
@@ -6,35 +6,34 @@
 freedom. But, v3 is incompatible with v2, because of the nature of
 copyleft. (The same issues will arise when a GPLv4 is needed.)
 
-Thus, for savannah hosting we require that you release your software
+Thus, for Savannah hosting we require that you release your software
 under GNU GPL version 2 or 3, *or any later version*. If you don't put
-this clause in the files now, the only way to use your program with GPL
-v3 code would be to ask each and every copyright holder, and that may be
+this clause in the files now, the only way to use your program with GPLv3
+code would be to ask each and every copyright holder, and that may be
 very difficult, even impossible (e.g. if a contributor is not reachable
 anymore).
 
 Some people worry about apparently giving the FSF (who publishes the GNU
 GPL) the ability to arbitrarily relicense their project. This is not the
-case, per section 9 of the GNU GPL:
+case, per section 9 of the GNU GPL (emphasis added):
 
-"The Free Software Foundation may publish revised and/or new versions of
-the General Public License from time to time. **Such new versions will
-be similar in spirit to the present version,** but may differ in detail
-to address new problems or concerns."
+> The Free Software Foundation may publish revised and/or new
+> versions of the General Public License from time to time.
+> **Such new versions will be similar in spirit to the present
+> version,** but may differ in detail to address new problems or
+> concerns.
 
-(emphasis added). The very essence of the GNU GPL is copyleft, so your
-code will remain protected.
+The very essence of the GNU GPL is copyleft, so your code will remain
+protected.
 
-GPLv3+ is generally recommended. See
-<http://www.gnu.org/licenses/gpl.html>
-for the complete text, which includes the recommended license notice to
-put in your files.
+GPLv3+ is generally recommended. See [the complete
+text](//www.gnu.org/licenses/gpl.html), which includes the recommended
+license notice to put in your files.
 
-LGPLv2.\* licenses are a different case. Because all these versions
-of the LGPL can
-be converted to any version of the GPL, we can accept LGPLv2.\*-only on
-savannah. Of course, we highly recommend against using LGPL\*-only when
-there is any alternative.
+LGPLv2.\* licenses are a different case. Because all these versions of
+the LGPL can be converted to any version of the GPL, we can accept
+LGPLv2.\*-only on savannah. Of course, we highly recommend against
+using LGPL\*-only when there is any alternative.
 
 Even if you yourself do not particularly care about the changes from
 GPLv2 to GPLv3, realize that a large body of code is released under
@@ -42,7 +41,7 @@
 cannot occur (in either direction), and that is the shame. Please use
 -or-later.
 
-Links:
-<http://www.gnu.org/licenses/gpl-faq.html#VersionTwoOrLater>
-from the GNU GPL FAQ
-<http://www.gnu.org/licenses/rms-why-gplv3.html>
+See also:
+
+- [GPL FAQ](//www.gnu.org/licenses/gpl-faq.html#VersionTwoOrLater)
+- [Why GPLv3](//www.gnu.org/licenses/rms-why-gplv3.html)

Modified: trunk/sviki/HowKnowIfALicenseIsFreeIn3Points.mdwn
===================================================================
--- trunk/sviki/HowKnowIfALicenseIsFreeIn3Points.mdwn   2023-02-07 09:32:21 UTC 
(rev 553)
+++ trunk/sviki/HowKnowIfALicenseIsFreeIn3Points.mdwn   2023-02-07 09:34:31 UTC 
(rev 554)
@@ -1,13 +1,16 @@
+# How to know if a license is free
+
 A license is free if:
-:   -   You can freely use it.
-    -   You can freely modify it.
-    -   You can freely share it, with or without modification, with
-        others.
+- You can freely use it.
+- You can freely modify it.
+- You can freely share it, with or without modification, with others.
 
-This works for permissive licenses, the official position is in 4
-points:
-<http://www.gnu.org/philosophy/free-sw.html>
+For further details, see the [Free Software
+Definition](//www.gnu.org/philosophy/free-sw.html).
 
-See also "Maintaining Permissive-Licensed Files in a GPL-Licensed
-Project: Guidelines for Developers" at
-<http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html>
+## See also
+
+- [GNU License List](//www.gnu.org/licenses/license-list.html)
+- [Maintaining Permissive-Licensed Files in a GPL-Licensed Project:
+  Guidelines for
+  
Developers](https://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html)

Modified: trunk/sviki/MirroringExternalRepository.mdwn
===================================================================
--- trunk/sviki/MirroringExternalRepository.mdwn        2023-02-07 09:32:21 UTC 
(rev 553)
+++ trunk/sviki/MirroringExternalRepository.mdwn        2023-02-07 09:34:31 UTC 
(rev 554)
@@ -1,13 +1,15 @@
+# Mirroring packages hosted elsewhere
+
 Our goal is to provide services, not just bandwidth.
 
-However, since our original goal is to provide services for GNU
-projects, we can, as an exception, mirror GNU projects whose main
+However, since our original goal is to provide services for the GNU
+Project, we can, as an exception, mirror GNU packages whose main
 development platform is not Savannah.
 
 This has to be done manually. Submit a support request if you need it. A
 requirement is to provide us with rsync access to your repository.
 
-Technically: create a `projectnamersync` user, member of `projectname`,
+Technically: create a `packagenamersync` user, member of `packagename`,
 then go to /subsystems/cvs/etc/cron.d/rsync\_external\_cvs\_repositories
 and follow the template. The mirroring process will exclude CVSROOT/
 ([[AccessToCVSROOT]] for details), except CVSROOT/history and

Modified: trunk/sviki/ModifyingGroupType.mdwn
===================================================================
--- trunk/sviki/ModifyingGroupType.mdwn 2023-02-07 09:32:21 UTC (rev 553)
+++ trunk/sviki/ModifyingGroupType.mdwn 2023-02-07 09:34:31 UTC (rev 554)
@@ -1,8 +1,10 @@
-If the project accidentally applies with the wrong Group Type such as
-"Official GNU" and it is in the Status of "Pending", you may update it
+# Modifying group type
+
+If the group accidentally applies with the wrong Group Type such as
+"Official GNU" and it is in the status of "Pending", you may update it
 from the Group Administration page.
 
--   Login as Savannah superuser
--   Update the project changing it to the correct Group Type.
--   Leave the Status of "Pending" and click 'Update' from the General
-    Settings section.
+- Login as superuser.
+- Update the group changing it to the correct Group Type.
+- Leave the status of "Pending" and hit 'Update' from the General
+  Settings section.

Modified: trunk/sviki/NonGnuToGnuSysadmin.mdwn
===================================================================
--- trunk/sviki/NonGnuToGnuSysadmin.mdwn        2023-02-07 09:32:21 UTC (rev 
553)
+++ trunk/sviki/NonGnuToGnuSysadmin.mdwn        2023-02-07 09:34:31 UTC (rev 
554)
@@ -1,34 +1,33 @@
-Moving from non-GNU to GNU (for savannah administrators):
+# Moving from nongnu to gnu (for Savannah administrators):
 
--   Change project type for the Savane project.
+-   Change group type.
 
     This is in the left-hand menu,
-    `Site Administration / Main Page -> Browse Groups List`. Change to
-    GNU and hit the update button. Do not use the icons at the top
-    (check mark and wrench+screwdriver).
+    `Site Administration / Main Page -> Browse Group List`. Change to
+    GNU and hit the update button.
 
 -   FTP uploads to ftp.gnu.org & alpha.gnu.org are done by the maintainer.
 
     Contact is <mailto:ftp-upload@gnu.org>,
-    maintainers should follow
-    <https://www.gnu.org/prep/maintain/html_node/Automated-FTP-Uploads.html>.
+    maintainers should follow [Automated FTP Upload
+    
instructions](//www.gnu.org/prep/maintain/html_node/Automated-FTP-Uploads.html).
 
--   Project admins should change their download area to
+-   Group admins should change their download area to
     alpha.gnu.org or ftp.gnu.org.
 
     The change is made by editing the download http:/https: address in
-    `Main > Administer > Select Features` from the project page. It's
+    `Main > Administer > Select Features` from the group page. It's
     just a matter of pointing to the right location, no system action is
     done (no cron jobs, etc.).
 
-    GNU projects have access to the Savannah download area, but
+    GNU packages have access to the Savannah download area, but
     ordinarily shouldn't use it.
 
--   Launch a curl to update www.gnu.org/software/PROJECT -- the
+-   Launch a curl to update www.gnu.org/software/GROUP -- the
     appropriate command from mgt0:/opt/administration/curl.txt.
 
     This will also automatically create a redirection from
-    www.nongnu.org/PROJECT to www.gnu.org/software/PROJECT. It works via
+    www.nongnu.org/GROUP to www.gnu.org/software/GROUP. It works via
     a web service at www.gnu.org maintained by GNU sysadmin.
 
 -   Mailing lists: check [[ListServer]] for non-gnu to gnu list

Modified: trunk/sviki/SavannahCountryRestrictions.mdwn
===================================================================
--- trunk/sviki/SavannahCountryRestrictions.mdwn        2023-02-07 09:32:21 UTC 
(rev 553)
+++ trunk/sviki/SavannahCountryRestrictions.mdwn        2023-02-07 09:34:31 UTC 
(rev 554)
@@ -1,6 +1,7 @@
-Question about restricting access per country
---------
+# Blocking access from certain countries
 
+## Question
+
 I noticed that SourceForge and Google code both are blocking access to
 the platforms for people from a number of countries (Iran, Syria, Cuba,
 ...).
@@ -8,8 +9,7 @@
 As far as I understood, Savannah is also US-based. Is there the danger
 that Savannah will also block access from these countries?
 
-Answer
-------
+## Answer
 
 We talked about it recently at FOSDEM and LSM, and our answer is that we
 do not block people based on their country.
@@ -18,7 +18,7 @@
 that US law does not require blocking connections from anywhere.
 
 Note: SourceForge softened their policy a bit:
-<http://sourceforge.net/blog/some-good-news-sourceforge-removes-blanket-blocking/>
+<https://sourceforge.net/blog/some-good-news-sourceforge-removes-blanket-blocking/>
 
 The country-based restrictions are in place by default, but you can turn
 them off in the sf web pages, under: Develop -\> Project Admin -\>

Modified: trunk/sviki/UpstreamCollaboration.mdwn
===================================================================
--- trunk/sviki/UpstreamCollaboration.mdwn      2023-02-07 09:32:21 UTC (rev 
553)
+++ trunk/sviki/UpstreamCollaboration.mdwn      2023-02-07 09:34:31 UTC (rev 
554)
@@ -1,3 +1,5 @@
+# Working with upstream 
+
 Sometimes, when a submitted project bears a strong relationship with
 another project ("upstream"), we ask the submitter to consider working
 with that other project, instead of working separately with a distinct
@@ -9,10 +11,10 @@
     maintainers would like to include it directly in their repository,
     perhaps in the form of a branch, rather than seeing you maintain a
     distinct version of their package.
--   a project translation: this is commonly done by maintaining .po
+-   project translation: this is commonly done by maintaining .po
     files in the original package, rather than in a separate project.
 -   internationalization ("i18n") effort: this is similar to adding a
-    new feature - for example, adding support for Asian or Indian
+    new feature&mdash;for example, adding support for Asian or Indian
     writing systems, which is more difficult than just providing Unicode
     support. If you develop your i18n effort separately, you will have
     to follow the development of the upstream package, and you'll
@@ -20,20 +22,23 @@
     efficient to work with the upstream maintainers to directly improve
     their package i18n features.
 
-Of course there are exceptions:
+Of course there are exceptions, e.g.:
 
--   maybe it is not easy to get write access to the upstream repository.
--   maybe you cannot work with patches, because the new feature /
-    translation is an effort involving multiple co-workers.
+- it is not easy to get write access to the upstream repository;
+- you cannot work with patches, because the new feature is an
+  effort involving multiple co-workers.
 
 When Savannah can offer a useful service to your project, we will gladly
-provide you an account (provided your project meets our hosting
+provide you a group (provided your project meets our hosting
 criteria, of course).
 
-Do not take it badly if we ask why you need the Savannah project - often
-we get submissions for people who did not see the cons in working
-separately or did not think about working with the upstream maintainers.
-We just make sure that this option was considered.
+Do not take it badly if we ask why you need a Savannah
+group&mdash;often we get submissions for people who did not see the
+cons in working separately or did not think about working with the
+upstream maintainers.  We just make sure that this option was
+considered.
 
-Our goal is not to get as many Savannah projects but as many quality
+Our goal is not to get as many Savannah groups but as many quality
 pieces of free software as possible :)
+
+See also: [[Hosting translations|AboutTranslations]]

Modified: trunk/sviki/WhyLegalChecksBeforeRelease.mdwn
===================================================================
--- trunk/sviki/WhyLegalChecksBeforeRelease.mdwn        2023-02-07 09:32:21 UTC 
(rev 553)
+++ trunk/sviki/WhyLegalChecksBeforeRelease.mdwn        2023-02-07 09:34:31 UTC 
(rev 554)
@@ -6,9 +6,9 @@
 copyright in the law.
 
 That's why we want the legal parts of the packaging job to be done
-before the project is approved at Savannah -- notably including valid
-copyright notices ([[ValidNotices]]) and inclusion of the full text of
-your project's license ([[ProjectApproval]],
+before the package is approved at Savannah&nbsp;notably including
+[[valid copyright notices|ValidNotices]]) and inclusion of the full
+text of your package license ([[ProjectApproval]],
 [[HowToGetYourProjectApprovedQuickly]]).
 
 In short, "release" in the legal sense is not only packaging a tarball.