diff --git a/HACKING b/HACKING
index bd3861c3..5181acb7 100644
--- a/HACKING
+++ b/HACKING
@@ -123,6 +123,12 @@ We try to be quite consistent, but of course, that's not always possible.
 
   There is semantic value to using "new." It's good CBSE. --Ted
 
+  There's no semantic value. It's reasonable to infer that any function
+  named in CamelCase is a constructor. That's the case with all such
+  internal functions. As far as I'm concerned, 'new' is a hack. Actually,
+  most of JS is a hack...
+    --Kris
+
 == Testing/Optimization ==
 
 TODO: Add some information here about testing/validation/etc.
@@ -138,5 +144,18 @@ TODO: Document the existence of remote branches and discuss when and how
       to look if an old branch needs to be maintained or a feature needs
       to be added to a new branch. Keep in mind that git is not the most
       intuitive SCM.
+    I don't agree. git is about as intuitive as any other SCM, but,
+    regardless, it's by far one of the most popular. There are
+    countless git walkthroughs, FAQs, tips pages (not to mention 'git
+    help') that I don't see the need to duplicate them here. As for
+    branches, 'git branch' should be sufficient, and, if not, there's
+    a list on gitweb. --Kris
+        I wasn't trying to say that git was a problem (though other DVCS
+        have more accessible help systems; except for very complex
+        projects, I think Mercurial is a much more comfortable DVCS to
+        learn, use, and navigate). I was saying that it might be nice if
+        the remote branches (and related polices) were documented. Yes,
+        anyone can do a "git branch -r", but seeing that a branch exists
+        is not the same as understanding why it's there. --Ted
 
 # vim: set ft=asciidoc fdm=marker sw=4 ts=4 et ai:
diff --git a/vimperator/TODO b/vimperator/TODO
index 2f3f6971..4300919c 100644
--- a/vimperator/TODO
+++ b/vimperator/TODO
@@ -98,19 +98,6 @@ FEATURES:
   have a look into the split browser extension
 1 Add information to liberator/HACKING file about testing and optimization
 1 Document remote branches in liberator/HACKING
-    I don't agree. git is about as intuitive as any other SCM, but,
-    regardless, it's by far one of the most popular. There are
-    countless git walkthroughs, FAQs, tips pages (not to mention 'git
-    help') that I don't see the need to duplicate them here. As for
-    branches, 'git branch' should be sufficient, and, if not, there's
-    a list on gitweb. --Kris
-        I wasn't trying to say that git was a problem (though other DVCS
-        have more accessible help systems; except for very complex
-        projects, I think Mercurial is a much more comfortable DVCS to
-        learn, use, and navigate). I was saying that it might be nice if
-        the remote branches (and related polices) were documented. Yes,
-        anyone can do a "git branch -r", but seeing that a branch exists
-        is not the same as understanding why it's there. --Ted
 1 Reformat liberator/HACKING so that git diff can find sections and report changes @ somewhere
 - many other ideas are listed in the wiki