Improve the intro page
authorNick Downing <nick@ndcode.org>
Tue, 18 Jan 2022 04:50:29 +0000 (23:50 -0500)
committerNick Downing <nick@ndcode.org>
Tue, 18 Jan 2022 04:50:29 +0000 (23:50 -0500)
_config/nodemailer_contact.json
_config/nodemailer_feedback.json
_config/nodemailer_noreply.json
index.html.jst

index 2106ceb..f98e2ec 100644 (file)
@@ -4,7 +4,7 @@
   "secure": false,
   "auth": {
     "user": "contact@ndcode.org",
-    "pass": "XXXContact12"
+    "pass": ",b4UtuaEj6"
   },
   "requireTLS": true
 }
index 675f676..8104cb2 100644 (file)
@@ -4,7 +4,7 @@
   "secure": false,
   "auth": {
     "user": "feedback@ndcode.org",
-    "pass": "XXXFeedback12"
+    "pass": "{22fPwun4m"
   },
   "requireTLS": true
 }
index 0b1a828..7012e82 100644 (file)
@@ -4,7 +4,7 @@
   "secure": false,
   "auth": {
     "user": "noreply@ndcode.org",
-    "pass": "XXXNoreply12"
+    "pass": "NM7ffn(4pT"
   },
   "requireTLS": true
 }
index dc2a4f7..984a88a 100644 (file)
@@ -16,10 +16,10 @@ return async env => {
 
       h4 {'About this site'}
 
-      p {'This site serves as a repository for my open-source projects. Smaller projects will show up as a blog entry, and for long-term projects this expands to a project page, tutorials, online documentation and so forth. I would also welcome any contributions you may have.'}
+      p {'This site serves as a repository for my open-source projects. Smaller projects will show up as a blog entry, and for long-term projects this expands to a project page, tutorials, online documentation and so forth. I would also welcome any feedback or contributions you may have.'}
 
       p {
-        'My '
+        'Public '
         tt {'git'}
         ' source code repositories are at '
         a(href="https://git.ndcode.org") {'https://git.ndcode.org'}
@@ -30,11 +30,27 @@ return async env => {
         ' sites, where I could monetize it later if I saw fit.'
       }
 
+      h4 {'How to contribute'}
+
+      p {
+        'Patches can be emailed to me at nick ‘at’ ndcode ‘dot’ org, and I can give '
+        tt {'git'}
+        ' write access to trusted contributors. I do '
+        i {'not'}
+        ' favour the new-fangled way of forcing people to contribute via Pull Requests (PRs) on github. At least in my case, this discourages contributions in the first place, because it becomes the contributor’s responsibility to edit the patch into an acceptable form and to push it through the system. I am grateful for any contribution you can provide, however rough, and if I think it’s not ready for merging then I will improve it or otherwise handle the situation as I see fit.'
+      }
+
+      h4 {'Copyright and licensing'}
+
+      p {'The projects on this site are open source and they are mainly MIT licensed or GPLv2’d. Generally, anything you might want to use in production will be MIT licensed, to give you complete freedom. Things you would only use in the development stage, such as code generators, are more likely to be GPLv2’d, but with appropriate exceptions to allow unrestricted use of the generated code. I don’t use GPLv3, as I regard the anti-Tivoization clauses to be too strict.'}
+
+      p {'Commercial use of my code is freely licensed because I believe the days of shrink-wrapped software are over, and it’s essentially the customization process that provides the value. So please go ahead and incorporate the code, and should you require customization or in-depth consulting for your application later on, then I can do so for an appropriate fee. Usually this is on a non-exclusive basis, so that if I add features on your behalf, I can also release them generally.'}
+
       h4 {'About my coding style'}
 
-      p {'I like precision and I generally don’t leave unhandled cases in my code. (In my long career as a professional programmer I’ve encountered Murphy’s Law on a regular basis). I also prefer consistency in matters such as identifier naming, indenting and so on.'}
+      p {'I like precision and I generally don’t leave unhandled cases in my logic, unless they are clearly flagged by assertions and such like. (In my long career as a professional programmer I’ve encountered Murphy’s Law on a regular basis). I also prefer consistency in matters such as identifier naming, indenting and so on.'}
 
-      p {'Having said that, my emphasis is on productivity rather than dotting i’s and crossing t’s. So my code is generally quite rough until I decide it needs to be polished up for release. As an example, suppose I’m writing a language compiler. Any language features that I do not use will not be implemented and will crash with an assertion failure or similar. I rely on people like yourself to download and exercise my code and inform me of the features you’ll use.'}
+      p {'Having said that, my emphasis is on productivity rather than dotting i’s and crossing t’s. So my code is generally quite rough until I decide it needs to be polished up for release. As an example, suppose I’m writing a language compiler. Any language features that I do not use will not be implemented and will crash with an assertion failure or similar. This lets me get up and running quickly with a basic feature set (and pass trivial test cases almost immediately). In the longer term I rely on people like yourself to download and exercise my code and inform me of the features you’ll use.'}
 
       p {'I also rarely use comments in my code. One of the reasons why I avoid commenting, is that often you spend inordinate amounts of time writing up the interfaces and algorithms used in your code in great detail in comments, and then change your mind and delete big blocks of code—along with those painstakingly constructed comments. If you do not invest too much in the code in the first place, it’s easier to delete and refactor.'}