From a502d96a860456ec5e8c96761db70f7cabb74751 Mon Sep 17 00:00:00 2001
From: Paul Martin <paul@paulsputer.com>
Date: Sat, 30 Apr 2016 04:19:14 -0400
Subject: [PATCH] Merge pull request #1073 from gitblit/1062-DocEditorUpdates

---
 src/site/tickets_overview.mkd |   27 +++++++--------------------
 1 files changed, 7 insertions(+), 20 deletions(-)

diff --git a/src/site/tickets_overview.mkd b/src/site/tickets_overview.mkd
index 485ca06..10d0e18 100644
--- a/src/site/tickets_overview.mkd
+++ b/src/site/tickets_overview.mkd
@@ -70,7 +70,7 @@
 1. The organizational unit of the Gitblit Tickets feature is the *ticket*.
 2. A *ticket* can be used to report a bug, request an enhancement, ask a question, etc.  A ticket can also be used to collaborate on a *patchset* that addresses the request.
 3. A *patchset* is a series of commits from a merge base that exists in the target branch of your repository to the tip of the patchset.  A patchset may only contain a single commit, or it may contain dozens.  This is similar to the commits in a *Pull Request*.  One important distinction here is that in Gitblit, each *Patchset* is developed on a separate branch and can be completely rewritten without losing the previous patchsets (this creates a new patchset).
-4. A *ticket* monitors the development of *patchsets* by tracking *revisions* to *patchsets*.  The ticket alslo monitors rewritten patchsets. Each *patchset* is developed on it's own Git branch.
+4. A *ticket* monitors the development of *patchsets* by tracking *revisions* to *patchsets*.  The ticket also monitors rewritten patchsets. Each *patchset* is developed on it's own Git branch.
  
 Tracking *patchsets* is similar in concept to Gerrit, but there is a critical difference.  In Gerrit, *every* commit in the *patchset* has it's own ticket  **AND** Git branch.  In Gerrit, *patchsets* can be easily rewritten and for each rewritten commit, a new branch ref is created.  This leads to an explosion in refs for the repository over time.  In Gitblit, only the tip of the *patchset* gets a branch ref and this branch ref is updated, like a regular branch, unless a rewrite is detected.
 
@@ -114,36 +114,23 @@
 
 Additionally, because the patchset is not linked to a user's personal fork it is possible to allow others to collaborate on development.
 
-## Status
+#### Features
 
-The Tickets feature is highly functional but there are several areas which need further refinements.
-
-#### What is working
-
+- My Tickets page
 - Ticket creation and editing
-- Ticket creation on patchset push
+- Ticket creation on patchset push (proposal)
+- Branch-based pull-requests
 - Comments with Markdown syntax support
 - Rich email notifications
 - Fast-forward patchset updates and patchset rewrites
 - Voting
 - Watching
 - Mentions
-- Partial milestone support
+- Milestones
 - Querying
 - Searching
 - Is Mergeable test on view ticket page load
+- Server-side merge
 - Close-on-push of detected merge
 - Multiple backend choices
-- Server-side merge (testing)
 
-#### TODO
-
-- Implement a My Tickets page (ticket-15)
-- Ticket Lifecycle Hooks (ticket-16)
-- CRUD pages for Milestones (ticket-17)
-- Ticket service migration tool (ticket-19)
-- Collapsible ticket description (e.g. AUI expander)
-- Edit a comment
-- Delete a comment
-- REST API for tooling
-- Client-side Markdown previews (AngularMarkdown?)

--
Gitblit v1.9.1