- How about a list-table-triggers command?

- Set a hub's topics.kind back to 'project' and make update-hub call
  update-project. I just got caught out wondering why "update x" wasn't
  calling the code I expected. Consider removing new-hub in favour of
  new-project --hub? Or we know that a project becomes a hub
  automatically when it is pushed to a repository? When it has no
  parents?

- How about synching all work_buffers rows back to the user repo,
  referencing uuids where necessary? Then perhaps some manual restore
  to get them back in the event of a rebuild.

- Implement a sync --log option that displays changes received.

- Use integers in a priorty field? Overall priority could be
  status.rank + priority, and the bif-list-* commands could select
  where total_priority > $VALUE. Could make "closed" rank = 0, and
  ignored rank = -1, then search for issues > 0, ordered by
  total_priority maybe makes sense.
  
- Add topics.path column (or maybe just task.path, issues.path)

- Use the SQLite backup API for uprades

- Make the bif manual a *reference* only document meaning that the
  tutorial info should go somewhere else. Perhaps bif-doc-tut? Keep
  extending bif-doc-intro?

- Prevent push-issue pushing to same project

- How long does an ID need to be?

    https://eager.io/blog/how-long-does-an-id-need-to-be/?n

- Investigate use of Text::Fold instead of Autoformat

- bifsync $SIG{__WARN__} handler into log::any->warn

- per repo bifkv last_sync values

- Store tree information for issue push history to be shown by
  bif-show-issue?
    
    [todo@hub] 3 days ago
    ├── [todo2@hub] 3 days ago
    └── [p2@upstream] 1 minute ago

- Conceptual thought: at the moment creating an issue in a project
  means that the issue is automatically synchronised with the
  projects.hub_id just like a project is. What if:

    - projects are visible on hubs other than projects.hub_id
    - issues create against the projects from other hubs are associated
      only with the hub where the issue is created, and not necessarily
      auto-synchronised up to the projects.hub_id.

    - bif push issue ID .... HUB? Perhaps one needs globally unique
      project names with the full path referring to the organisation:

        my.project@hub.one
        my.project@hub.two

      where the my.project uuid is common, as opposed to the current
      model where the uuids (and therefore the projects) are different
      even if they have the same name.
  
* entrypted bifax.org

* Handle trailing spaces in YAML formatting when columns are NULL

* Use Term::Readline::Tiny

* Record update_id created by each command in
repo_deltas.first_update_id and repo_deltas.last_update_id. Then "show
$SOMETHING repo.update_id" can indicate the changes that occured when a
"sync" was performed. Or maybe "bif list sync-updates". Perhaps "bif
log repo" should be renamed to "bif list repo-updates"? or just "bif
list updates"

* Show related projects in "show project"

* Properly fix the whole reply/update mess

* After being pushed to a hub does a project need to keep
hub_related_updates for the local hub?

* Don't print Hub: lines for "show project" when project has no (or
local) hub.

* Think about the difference in transactions between clients and
servers. For example, a project push can fail due to an issue/task
problem, but at the moment Bif::Sync::Server will commit the addition of the
project to its hub_related_updates table while the client doesn't. One
solution is possibly to dynamically generate and sync the hub merkle
tree based on ... project_updates_merkle if it existed? We might
want that table anyway because of shallow exports for hub-to-hub
cooperation.

* Hide IDs in show issue for projects that are not local.

* Use Test::Kit[2]

* Instead of magically matching arguments against an ID, ALIAS,
LOCATION etc, require an option to specify exactly what the input is,
like we are starting to do with UUIDs.

* Make a code of conduct. How about borrowing Debian's:
    https://www.debian.org/vote/2014/vote_002

* Put the protocol version number in the location uri?

    ssh+bs1://org@provider.com
    bif1+ssh://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_deltas
      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 push project 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 push project $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 a project push (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.


from http://collectivebim.com/future-issue-tracking-aec/:

At a minimum, a proper issue tracking method should include the ability to:

    define the type of issue (clash, data deficiency, model craft)
    store meta-data about an issue (priority, location, date found)
    take an issue through a defined workflow / change of status manage
    comments from multiple parties define who is responsible for
    resolving the issue keep all information above intact throughout
    model development be accessed by entire team regardless of their
    platform or experience.
