--- a/database/schema/TODO	Mon Jun 16 01:27:45 2014 -0400
+++ b/database/schema/TODO	Mon Jun 16 01:27:54 2014 -0400
@@ -1,43 +1,49 @@
--- Does not handle:
---
--- * The Description, How-To-Repeat, and Fix fields from gnats are
---   supposed to just be the initial entries in the message log, but
---   they're currently also in the bugs table. Also "unformatted".
---
--- * There is no administrative queue yet.
---      - comments on locked PRs
---      - comments on nonexistent PRs
---      - bounced mail from feedback requests
---      - other bounced mail
---      - unreocgnized/junk/malformed mail?
---      - action requests in commit messages like Christos wants
---
--- * "Category" is just a classification scheme, but we need to know
---   (based on the category) what default subscriptions to create.
---   There's currently no way to do this. Since the script for
---   accepting incoming PRs needs to know about the gnats schema
---   anyway, perhaps there should just be a table in the database to
---   tell it what to do.
---
+############################################################
+# states
+
+If we want feedback PRs with no respondents to go to "stuck" we need
+to store the string "stuck" somewhere. (And, what about non-feedback
+PRs with no responsible people?)
+
+############################################################
+# hooks and custom stuff
+
+"Category" is just a classification scheme, but we need to know (based
+on the category) what default subscriptions to create.  There's
+currently no way to do this. Since the script for accepting incoming
+PRs needs to know about the gnats schema anyway, perhaps there should
+just be a table in the database to tell it what to do. That table
+doesn't exist yet.
+
 -- * There also needs to be a hook to deduce the package name for
 --   pkgsrc PRs by scanning the synopsis. This is going to be netbsd-
 --   specific; making it table-driven isn't feasible and probably it's
 --   not worth (at least at first) setting up a whole scheme for
 --   site-specific extensions. So probably it'll be hard-coded in at
 --   least to begin with.
---
+
+############################################################
+# administrative queue
+
+The administrative queue should probably also have a queue for actions
+requested by commit messages. (Christos wants to be able to put
+something like "PR 12345: close" in commit mails, which is probably a
+good feature, but these need to be scanned by somebody to avoid
+accidents.)
+
 -- * There should be an incoming queue for stuff submitted via the web
 --   interface, because a lot of it will be spam.
 --
 -- * There should be a whitelist/blacklist for that queue, by IP
 --   address or netblock.
---
--- * Should support automatic feedback timeout.
---
+
+############################################################
+# other stuff
+
 -- (the stuff below this point probably isn't getting done before the
 -- initial deployment)
 --
 -- * Should be able to merge duplicates.
 -- * Should allow recording dependencies between bugs.
 -- * Should store pullup numbers
---
+