git-tickets

commit

268cd35ec904265d562dbb4cfe3452d9f8989522

parent

f4a82b51451b67dc711a066cdbcf0ba7486a2f33

Author

Tobias Bengfort <tobias.bengfort@posteo.de>

Date

2017-07-16 17:30

rm "Possible Enhancements" from readme

these have been converted to tickets

Diffstat

1 files changed, 0 insertions, 59 deletions

diff --git a/README.md b/README.md

@@ -83,65 +83,6 @@ levels:
   83    83 	-	simple references to tickets, users, and code [not yet done]
   84    84 
   85    85 
   86    -1 ## Possible Enhancements
   87    -1 
   88    -1 ### References
   89    -1 
   90    -1 A notable github feature is still missing in git-tickets: A simple way to
   91    -1 reference tickets, users, and code. On [github][github-refs], the following
   92    -1 references are possible:
   93    -1 
   94    -1 -	`@{user}`
   95    -1 -	`#{ticket}`
   96    -1 -	`{commit-hash}[#diff-{file-hash}[R{line}]]`
   97    -1 
   98    -1 The string `fix #{ticket}` somewhere in a commit or pull-request will
   99    -1 automatically close that ticket on merge. Also, a ticket automatically contains
  100    -1 back-references to tickets or commits that reference it.
  101    -1 
  102    -1 A simple way to have similar (though very limited) functionality is to use
  103    -1 [tig] as a pager. This will allow to automatically link to a commit from a line
  104    -1 like this:
  105    -1 
  106    -1 	commit {hash}
  107    -1 
  108    -1 There has been a [feature request][tig-feature-request] to extend this syntax
  109    -1 for a long time, but nobody seems to be particularly interested.
  110    -1 
  111    -1 ### New headers
  112    -1 
  113    -1 The selection of message headers is currently very much inspired by github.
  114    -1 Some additional headers might be worth considering, e.g. to support use cases
  115    -1 such as "Incident Response Systems":
  116    -1 
  117    -1 -	`In-Reply-To` and `Message-Id` headers for threaded discussions.
  118    -1 -	`Labels` can be used to define some priority levels. A dedicated `Priority`
  119    -1 	header could allow more fine-grained control.
  120    -1 -	A `Timeout` or `Due` header to automatically change a ticket's priority over
  121    -1 	time.
  122    -1 -	A dedicated `Milestone` header.
  123    -1 -	Additional headers to allow statistical evaluation, e.g. `ClosedAt`.
  124    -1 
  125    -1 ### Tools
  126    -1 
  127    -1 -	The `git-tickets` tool in its current form is simplistic. It does not allow
  128    -1 	complex queries and can not handle folding/wrapping in tickets.
  129    -1 -	A read-only web interface in the spirit of [stagit] would be nice, but with
  130    -1 	filtering and reference links.
  131    -1 -	Currently, the only way to see what is going on is to fetch the "tickets"
  132    -1 	branch and read the log/diff. This has two downsides: (1) I do not receive
  133    -1 	notifications for urgent tasks and (2) it does not scale for large projects.
  134    -1 	A local service that fetches on intervalls and notifies me of relevant
  135    -1 	changes might be useful.
  136    -1 -	This seems to be a deal-breaker for many people, so a mail gateway may be
  137    -1 	necessary.
  138    -1 
  139    -1 ### Spec clarifications
  140    -1 
  141    -1 The spec is too strict in some places and too vague in others. Most
  142    -1 importantly, it can probably be extended to versioning systems other than git.
  143    -1 
  144    -1 
  145    86 ## FAQ
  146    87 
  147    88 ### `ls` just shows me a list of numbers. How am I supposed to find relevant tickets?