* Put the protocol version number in the location uri?

    ssh+bs1://org@provider.com

* Bug: Given an issue in two projects, pushing either of those projets
to a hub will fail because the second project doesn't exist at the hub.

    - two situations: importing a project containing an issue that
      refers to an existing project, or importing a project that is
      referred to by an existing issue. Probably means storing the
      project_uuid in the issue update and triggering things
      appropriately. Alternatively, we don't sync the issue_updates
      that refer to non-present projects?

* Trademark policy? http://modeltrademarkguidelines.org/

* http://developercertificate.org/

* Turn repo aliases into user aliases

* Possibly rework all func_* tables to use AFTER INSERT
triggers in order to get argument checking from SQLite. I'm considering
this because errors like "updates_pending.terms may not be NULL" are a
long way from where the real error occured. The question is perhaps
what this costs in terms of speed.

* Add internationalization support

* Add an --output [human|yaml|json] option

* Consistency: Should "log" be "showlog"? "show --log"?
    What about "show" with no ID doing a "list projects", in effect a
    "show all"? Conceptually show with no arguments is like a "show
    *repo*"

* Drop an issue seems to drop all related issues! What's the correct
desired behaviour?

* Bug identification for humans:
    ID at hub?
    - bif://3452@hub.provider/hub

    Project and ID and hub?
    - bif://project.3452@hub.provider/hub
    - bif://3452.project@hub.provider/hub
    - bif://3452@project@hub.provider/hub

    Not using a protocol...
        ID at hub?
        - 3452@hub.provider/hub
        Project and ID and hub?
        - project.3452@hub.provider/hub
        - 3452.project@hub.provider/hub
        - 3452@project@hub.provider/hub
        - 3452.project@hub@hub.provider

    Remember that push looks like this:

        bif push 3452 project hub.provider/hub

    So go back to looking at how one defines a hub + provider?  doesn't
    matter since one can use a hub alias?

        bif push 3452 project hubalias

    which is representative of

        bif push 3452 project organisation

    Do *not* fall into the trap of trying to make this look like
    English, because not everyone is native.

        b̶i̶f̶ ̶"̶p̶u̶s̶h̶ ̶i̶d̶ ̶3̶4̶5̶2̶ ̶t̶o̶ ̶p̶r̶o̶j̶e̶c̶t̶ ̶a̶t̶ ̶o̶r̶g̶a̶n̶i̶s̶a̶t̶i̶o̶n̶"̶̶

    Lars suggestions put the bug number at the end

        hub.provider/hub/3452
    
    Which starts to look sort of like a url, which could be useful when
    looking for bug web pages.

        hub.provider/hub/project
        hub.provider/hub/3452

    It would be nice to separate the bug/project/hub away from the
    provider location, because things move. In the end, using the uuid
    with a peer to peer network (al la TeleHash) is really the best for
    location. Just talk about issue bif#aab3e21 for definite reference?

    If there were no explicit hub providers, but every hub was hosted
    at an organisation then it looks a little better.

        bugs.debian.org/libdatetime-perl/3452

    See this for another option:

        http://blog.liw.fi/posts/distributed-bug-tracking/discussion/

        "As such, bug://apache2/keyword-description might be more
        useful"


    How about this, instead of bif@provider.com/org we do
    org@provider.com:

        #  With a provider
        bif register org@provider.com [org]

        #  With a self hosted hub server (defaults to bif@mydomain..)
        bif register mydomain.com [mydomain]

        bif export todo org
        bif push 39 libdata-uuid debian.org
        bif mv 39 libdata-uuid/version debian.org
        bif push 441 project/subproject org

* Consider if vector clocks are somehow useful/applicable

* Normalize unicode on input

* Simple default status types? open, stalled, closed
    - Possibly also ignored, but that could also be calculated based on
      a status value.
    - Much more common/known than 'active' and 'resolved'

* Consider creating own keypair?: ~/.bifhub/id_rsa[.pub]

* BifHub signup

    #!/bin/sh
    bifhub signup
    # Also bifhub signup [PROVIDER] [$SSH_HOST_KEY]
    # - Add $SSH_HOST_KEY to ~/.ssh/known_hosts?
    # - bif new contact # on first run
    #     Name: dsfsdfsdf
    #     Email: sdfsdjlsdfl
    #     SSH Public Key: ~/.ssh/id_rsa.pub
    #     uuid: 22ee2e2bdce # autogenerated
    # - copy public key to ssh://signup@bifhub.com
    # - bif import --type hub bifhub.com ssh://bifhub.com
    # - bif new account --from-contact $CONTACT_ID
    # - bif export $ACCOUNT_ID bifhub.com
    # - Confirmation key sent to email address

    bifhub list [providers] [--contact $ID]
    Provider       | Plan      | Valid      |  Hubs   | Issues  | Invoices 
    ---------------------------------------------------------------
    bifhub.com     | Private   | 2013-04-31 |       0 |       1 |        2 
    eu.bifhub.com  | Org       | 2014-02-18 |     2/5 |       0 |        1

    bifhub list hubs
    ID | Hub                        | Valid      | Issues  
    ------------------------------------------------------
    13 | bifhub.com/nomad@null.net  | 2013-04-31 |     1 

    bifhub create hub bifhub.com/debian.org

    bifhub list hubs
    ID | Hub                        | Valid      | Issues  
    ------------------------------------------------------
    13 | bifhub.com/nomad@null.net  | 2013-04-31 |     1 
    15 | eu.bifhub.com/debian.org   | 2014-02-18 |     2

    # The organisation owner does this for hubs that are not public
    bifhub invite nomad@nomad@null.net bifhub.com/debian.org

    bifhub update $ACCOUNT_ID --message $KEY
    bifhub sync $ACCOUNT_ID

    # .bif/ hubs are separate from ~/.bifhub/ providers
    bif list hubs
    ID  | Alias    | Hub       
    ------------------------------
    13  | upstream | bifhub.com/debian.org

* Remove all defaults from the "updates" table and force calling code
to be explicit about all values being inserted. This should make
testing easier (currently having problems with duplicates) and is also
necessary when porting to multi-user databases, where things like the
database timezone and language have nothing to do with the user
location.

* Bring back the "todo" project that serves as a catch all for tasks or
issues or general notes, that users don't want to categorize yet. See
the following for inspiration:

    https://medium.com/what-i-learned-building/df9809d53f88

* Put in place a mechanism for acknowledging the efforts of all
 contributors: See www.chesnok.com/daily/2013/06/26/giving-credit-to-reviewers/

* Future command?
    usage: bif assign ID OWNER [HUB]

    assign a topic's responsibility to an identity? Would depend on
    storing identities as topics.

        # import the identity - which is also project
        bif import mark bif://bifax.org/~mark

        # basically a push, but not tracked as a separate project,
        # but tracked with an 'assigned' field.
        bif assign 13 mark

* Consider email-like shortcuts for project/hub locations
        # bif import nomad bif://null.net/~nomad
        bif import nomad@null.net

        # perhaps no need to import the id first? just try based on the
        # email-like address - autoconvert it to "ID HUB"?
        bif assign 13 mark@bifax.org

* Subtasks are probably useful. What do they look like? How do they
 relate? See https://trello.com/tour for a checklist idea. Need to
 think about tasks that have multiple interested parties, and if you
 push a task can it be treated like an export (one status everywhere),
 instead of like an issue (multiple status).

* Use File::UserConfig

* Use MakeMaker PL_FILES to generate docs instead of
module::install::PRIVATE..

* Create a release checklist, since the automation tools aren't quite
 there for me.

* bif work ITEM [PROJECT] or similar

* Affero licence?

* Put aliases in .bif/alias/stuff.sql etc

* What does this do? From http://sql-info.de/postgresql/notes/logging-changes-to-postgresql-conf.html
    2. Create a view to show the most recent status of log table entries:

    CREATE OR REPLACE VIEW pg_settings_log_current
      AS  SELECT psl.*
            FROM pg_settings_log psl
       LEFT JOIN pg_settings_log psl_ref
              ON (psl.name = psl_ref.name
             AND psl.recorded_ts < psl_ref.recorded_ts)
           WHERE psl_ref.name IS NULL

* Read-only repositories (or topics? projects?), both "init
    --read-only-sync" (if you pull from me you can't update status) and
    "pull --read-only". "new project --read-only-export"? Or just do
    the whole thing with permissions?

* More thread types: "new feature", "new enhancement"?

* Normalize unicode content before INSERT
    - Possibly do in DBIx::ThinSQL?

* New model:
    - States become a boolean value.
    - "Current status" becomes the highest ranked true status
    - Put resolved status after closed status

* One line per sentence/comma

* Patch Sort::Versions or inline a new version to sort as humans would
 like when numbers don't contain any dots '.'.

* 'depends' should be on a 'project:id:<!active|!stalled>' variable.

* Determine if 'depends' can be across projects. If it is a per-project
 parameter, etc.

* Determine if 'depends' can be on aother project we have 'pushed' and
 issue to

* Prefix tree:

        1
       a  b
      f    e    f
  1af       1be 1bf


  1     x
  1 a   x
  1 a f x
  1 b   x    2. rm & fix
  1 b 7 x
  1 b e x    1. rm & fix
  1 b f x

* workflow?
    - State transition management without a new domain specific
      language?

* When creating a sub-project inherit the parent project task-status
 and issue-status? Better to specify '--from' or '--template' instead.

* Feature, Defect, Patch, Task, Enhancement, FAQ, Issue, Bug, ...
    - How to abstract all of this and make curo flexible enough to do
      all of the above?

* FAQ support
    $ curo new faqgroup
    $ curo list faqgroups

    $ curo new faq [GROUP]
    Project: documentation
    Question: What is the best way to make curo popular?
    Answer[/e to edit]: Buggered if I know

    $ curo list faqs

* Document how:
    - subtasks can be handled with sub-projects
    - milestones can be handled with sub-projects
    - tagging can be handled with sub-projects

* 'Assigned' support
    - only to a single user at any one time?
    - depends on user/contact support?
    - A per-project field?
    - Forget about it?

* sub-task support

* make 'depends' 'blocked'

* Index and and 'find' or 'search' command

* Include replied-to text as a comment inside the edit file

A global directory of org hashes? What if A -> B -> C. A updates. B
knows who it was because they have a hub pointingn to A. How about
another table of 'organisations' that the *_updates table references?

keywords:

    fractioned
    partial
    unified
    synchronised
    distributed
    federated
    derived
    fused (fusion)
    synthesized


    fractional synchronisation

    fracsync
    fracsynced


    unifyed.com

    uf init
    uf list
    uf new project
    


A fundamental improvement over most other bug tracking systems.

Uses a combination of hash tree, and prefix tree, and possibly
prefix-hash-tree?



Descriptions:

    Issue tracking systems usually integrate more with customers and
    customer issues. An issue could be "help me install this" or "How
    do I get the fubar into the flim flam." They could even be
    something like "I need an evalutation key for your software".

    Bug tracking systems help you keep track of wrong or missing things
    from the program.

    When looking at web systems, there is usually a big difference in
    focus, either helping customers or tracking problems with your
    software.



    The difference could be clearer from the following example.

    Suppose you had a production issue today that affected 5 customers, but
    was caused by a single software defect.

    In your issue-tracking system, you opened 5 tickets and started
    tracking what each customer reported, what was communicated to them,
    when the software patch was applied, etc. You can track that kind of
    stuff separately for each customer.

    In your bug-tracking system, you made 1 entry for the software defect
    started tracking things like steps to reproduce, code changes, etc.

    Customer issues can be closed whenever they're remedied to the
    customer's satisfaction and that may or may not involve fixing the
    software. The bug can be closed when it's fixed and retested.

    Two systems, outward- and inward-facing, tracking two different kinds
    of things, each with its own life cycle.

