You are not logged in. Log in. Or Sign up.

NOTE: Federation is disabled on this instance!

You can test federation between the following instances:
Vervis @
HomeSharersfr33domloverReposrel4tion-wikiFilesmaster tickets.mdwn

Mirror of the Rel4tion website/wiki source, view at <>

[[ 🧙 fr33domlover ]] :: [📥 Inbox] [📤 Outbox] [🐤 Followers] [🐔 Following] [🏗 Projects] [🗃 Repositories] [🔁 Workflows] [🐛 Tickets]
[[ 🗃 rel4tion-wiki ]] :: [📥 Inbox] [📤 Outbox] [🐤 Followers] [🤝 Collaborators] [🛠 Commits]


  • master
  • Tags

    master ::


    [[!template id=ticket-bucket-stats bydone=yes byclass=yes]]



    This is the main page of the ticket tracker.

    The ticket tracker tracks ideas, proposals, bugs, feature requests and more. It uses ikiwiki’s features for this, without any databases.

    Actually, this wiki has two trackers. If you want to insert a TODO item into an existing page, use the [[todo]] tracker instead of this one. The ticket tracker is for items which have dedicated pages, i.e. each ticket has a separate page.

    If you’re new here or you just have a few words to say or you’re confused by the instructions, you can instead use e-mail or IRC, or add your text to the [[/inbox]] page - but if you can spend another moment to put your ticket in the right place with the right tag, it will be greatly appreciated. It’s very simple once you read the instructions below.

    Each project or ticket collection maintains its own statistics. There is also a place for [[general tickets|general]], i.e. ones which aren’t specific to any project or section.

    Tickets are categorized into classes:

    Each one of these pages contains a summary of the open tickets which belong to it, and a description of that class, i.e. which kinds of tickets should use it. Closed tickets are listed separately here: [[done]].

    How to Use

    In various locations on the wiki, there are ticket pages. These pages serve a simple purpose: Collect tickets as subpages. Each subpage is a ticket. All the information of the ticket - description, status, discussion, patches, review - should be on its page (or subpages of it, if needed). If you want to create a new tickets, two locations you should probably consider are:

    1. Each project page should have a tickets subpage, under which you can place your new ticket.
    2. For a general ticket, place it under the [[general]] page (you still need to tag it).

    Ticket page names for most projects are just numeric identifiers (for easy reference) while the [[/ikiwiki/directive/meta]] title sets the human friendly title visible in the generated wiki pages. If this is your first time opening a ticket here, you can just type in a descriptive ticket name and it will be fixed later. Otherwise, pick the next available number (the first ticket in a project is always number 1) and use the meta directive for the title.

    In order for your new ticket to be categorized, you need to choose a single class for it. See the class list above and familiarize yourself with them. After you choose, the required minimum is to [[tag|/editing/tags]] your page with that class and with the page you are reading right now (/tickets), but what you should really do is use the [[ticket template|/templates/ticket]], which handles it for you and adds some info to your new ticket page. Here’s an example, with the [[class/task]] class:

    \[[!template id=ticket class=task]]
    My first ticket, woohoo! So let's start... hmmm... there are so many things
    to do , I'm not sure where to start. Let's just start by saving the world,
    and then re-assess the situation and make further decisions. Great! See you
    next week :-)

    Whenever you need to change the class of the ticket, simply edit that line. For example, a [[class/report]] from a user may become a [[class/problem]] after confirmation. A random [[class/thought]] may develop into an [[class/idea]], written in more detail as a full [[class/proposal]] and finally become a [[class/task]] to implement it.

    When you decide to close a ticket, the required minimum is to tag your ticket with [[done]] (but don’t remove the ticket class tag! Leave it there as is). Once again you can use the template. Simply set the done parameter:

    \[[!template id=ticket class=task done=yes]]
    My first ticket, woohoo! So let's start... hmmm... there are so many things
    to do , I'm not sure where to start. Let's just start by saving the world,
    and then re-assess the situation and make further decisions. Great! See you
    next week :-)
    (... a week later ...)
    I'm done saving the world and there are no more things to do right now. I
    think I'll start learning Hindi and write the book I always dreamed of.
    Also, my new solar-powered airplane is about to arrive from the
    wind-powered green airplane factory. Anyway, it's probably time to close
    this ticket. Ciao!

    Assigning to People

    Sometimes a ticket is open, but someone is working on it. If you work on a ticket, adding your name there will let others know there is progress being made. This will clarify the real picture of the project’s progress and will help people avoid accidentally doing something already being done by someone else.

    There are 2 ways to mark tickets as assigned to a person. You should probably use the first one. The other one isn’t normally needed.

    (1) Use the ticket template

    Use the assigned parameter of the ticket template, like this:

    \[[!template id=ticket class=task assigned=joe]]
    My first ticket, woohoo!

    If you have a page under [[/people]], in this example /people/joe, then your name will be mentioned as a link to that page. You can use this features in your personal area with the [[/ikiwiki/directive/inline]] directive to list the tickets assigned to you, or the hopefully more convenient [[/templates/my-open-tickets]] template.

    What the ticket template actually does is two things:

    While these tags can be inserted manually, there is probably no reason to do so. The ticket system of this wiki is already using the ticket template everywhere. However there is one case which the ticket template doesn’t handle: Having more than one assignee for a ticket. If you’d like to add a second or third assignee, use a tag directly.

    Patches and Branches

    If you have a patch to submit, put it under your ticket’s page. Give the patch file a .patch extension. For example, if the ticket page is foo_bar.mdwn, the patch may be foo_bar/save_the_world.patch.

    If it’s just a tiny quick thing, you could use diff:

    $ diff -u file1 file2 > hello.patch

    But you should prefer a patch generated by Git/Darcs, since it contains a commit message and your name and e-mail for version history and author credits.


    $ darcs record
    $ darcs send --output-auto-name


    $ git checkout -b fix-the-bug
    $ git commit
    $ git format-patch origin

    If instead you prefer a merge request (e.g. if it’s a big change with many commits and/or it needs improvements), simply specify the details of your Darcs repository or Git branch in your ticket page (clone URL, and browsing URL if exists).

    Command-Line Browsing

    If you are working with the Git repository (for viewing or editing or both), you may wish to go over open tickets, list them, filter them, sort them. But ticket pages in most projects are numbers. How to work with the meta titles on the command line?

    The answer is simple: Use grep. If you grep for the meta title, you’ll get a list of all the titles, and using the various coreutils you can manipulate the list (sort, filter, etc.). For example:

    $ grep 'meta \+title' projects/funbot/tickets/*.mdwn
    projects/funbot/tickets/1.mdwn:\[[!meta title="XMPP/Jabber support"]]
    projects/funbot/tickets/2.mdwn:\[[!meta title="Persistent state backend"]]
    projects/funbot/tickets/3.mdwn:\[[!meta title="Meeting system"]]
    projects/funbot/tickets/4.mdwn:\[[!meta title="Channel logging"]]
    projects/funbot/tickets/5.mdwn:\[[!meta title="Make the tell command remember messages"]]

    Planned Changes (TODO)

    Instead of manually inserting those tags into ticket pages, maybe there will soon be a ticket template. It will not only display the ticket class in a clear visible place, but also other details: Who’s working on the ticket, who else is interested in it, links to a patch or a git branch and so on.

    Make template support as needed for patches and branches

    [See repo JSON]