Mirror of the Rel4tion website/wiki source, view at <http://rel4tion.org>

[[ 🗃 ^yEzqv rel4tion-wiki ]] :: [📥 Inbox] [📤 Outbox] [🐤 Followers] [🤝 Collaborators] [🛠 Commits]

Clone

HTTPS: git clone https://vervis.peers.community/repos/yEzqv

SSH: git clone USERNAME@vervis.peers.community:yEzqv

Branches

Tags

master :: tickets / general /

14.mdwn

[[!template id=ticket class=proposal]]

[[!meta title=“Ticketing improvements”]]

The process of creating a ticket is pretty simple, but could be even more straightforward:

  1. The ticket template page is not what I expected. I thought it would have, well, a template: something I could copy-paste, then replace relevant sections, to create a new ticket with the correct format. I also would expect it to give all the possible statuses, but no context for how they should be used. Then I’d remove all that from the tickets explanation page, so the template page becomes a reference for how to create a ticket, and the tickets explanation page becomes an explanation of how tickets are intended to be used.

  2. I’d include all the stuff I just suggested putting on the ticket template page right on the tickets page, which would now read along the lines of “Create a new ticket by filling out the template below. Possible values are XYZ. See here for more information about tickets.”

  3. There are a lot of possible ticket statuses; are they really all necessary? I think there are 3 that are duplicates:

    • thought / idea
    • proposal / request
    • report / problem
    • task

–[[smichel17]]

Thanks for the feedback.

There’s a reason things work the way they do:

  1. ikiwiki’s web UI lets me specify the initial content of a new ticket page, but that works only when you create a ticket in the web UI. Since I don’t use the web UI most of the time and I wanted to give git users equal options, I decided not to take that path. I also didn’t care much because there’s so little activity here anyay.
  2. The ticket system in this wiki is a hack possible thanks to ikiwiki’s flexibility, but it’s not a powerful enough ticket tracker. I want to move to an actual tracker, once Vervis provides one. So don’t waste time and effort on this tracker. It’s going away anyway, and it’s limited anyway.
  3. Yes, I thought about it a lot and there are clear definitions for these classes and why they’re all needed. I don’t remember if I put it in a wiki page. I’d prefer to use some sort of semantic smart tags, but ikiwiki can’t do more than a simple list of page names to be used as tags. Here’s an example: Thought and idea, why do they both exist? Thought is the most general vague piece of text, that doesn’t fit anything else. Idea means your thought has the form “Perhaps we could do…”. Then you have proposal, which means “I suggest we do” and request, which means “I’d like you to do”. This may sould silly but it really helps prioritize tasks and track their progress as they change class from generic to specific. Sorry this is unclear in the docs.

I appreciate your feedback a lot, and I do want better ticket tracking, but I realized ikiwiki can’t do everything I want anyway, so I’m staying with this pseudo tracker thing until I move to something more powerful.

The best way to create a ticket is probably to copy and existing one and modify :-)

–[[fr33domlover]]

[See repo JSON]