wicketticket

this is an old draft, current project is github.com/klml/dikid and the doku

jetzt aber doch Dikid

wicketboard is a draft for a Issue Tracking System written as an extension or fork of pages, a wiki using couchapp with Couchdb. ''pages'', like every wiki, is IMHO a very good implementation for the Document-oriented database system of CouchDB. It shows the user documents as pages and lets you create and change them. And of course CouchApp is elementary and plain (no extra webserver, no extra script just JS)

This is the first draft of Notz {DIV(align=>left, width=>25%, float=>right, class="umijabox")}{DIV}

Additionally to the simple wikistructure (Wicketpage:Index), I tried to add some extra relations for the use of a tickestsystem (also known as bugtracker, Issue tracking system, project management system).

  • There a some threaded lists to show your tickets
  • as detailed ticket-view tickets/all
  • as simple to-do list-views line/all
  • input field to create new tickets
  • structured with all prios, user, duedate an more

  • bulked like a to-do list

  • no more single view, only lists (single vie is now a list with one item)

  • no more comments, only a list of refering tickets

Easy like mail or twitterdings... or other things people really use.

CouchApp

I am not really a coder, I just tried to learn a little bit, feel free to teach me.

The awesome in CouchDB is you can use JavaScript serverside, not so mighty like other frameworks, but mostly enough to pingpong some data (like Server Side Includes). The only, but very important thing, that you can't do is sending structured data via post. You have to prepare your data in JSON first. (This is only my experience, there could be another possibility)

For this you can use eventy, next to mustache, the most important part of CouchApp. Of course you can build a whole application with evently out of superglueing javascript. But I like real traditional html. So I tried to use mostly serverside generated html, not only in reason of ideology, but some advantage and necessity

  • submit (incl JSONing) is (at time?) in CouchDB only possible with evently
  • the form for new items or changes is handled by evently. Mostly these are optional on a side, so one advantage is I can load these initial on click (instead of html preloading and toggling)
  • global lists from ''CouchApp.json'' like the 'states' or 'queues' have to get to the user selectfield. So instead of rendering them on the server to the script and then reading it client side in JS i juts printed them in html, and grabbed it with jquery Selectable. But you could see these options without JS.
  • the document-categories itself, like 'state' and 'prio' but is important to be renderd serverside. So I have a little problem mixing html structure but JS chancging with evently
  • I cant have serverside inputs, editing these with JS and send them all. i hope il find an solution
  • the category control (called hottyper) is used on 2 points
    • existing documents
    • new
  • in both cases I need the category-proposal (called hottypes)

categories-structure

I made some thougts about "the right" structure for a issuesytem Outermarkdown

  • CouchDB is schemeless, so I only define datatype by my CouchAppdesign (it would be easy to create a type "feelings for this ticket" (♥ or ☠)
  • the possible values are given as inputs, this means a user can create types at Duck_typing and he is responsibel for this (if he writes 'mika' instead of 'mike', mike will not see the he is meant)
  • but for this wicketboard is overwhelmed by jQuery helpers on the client screen (sliders, dropdowsn selctabels). Presets are written in '/_attachments/presets.js' an used on every side. (TODO personalize presets)

Autofiller

Autofiller is automatic formfiller from your main input text

  • Autolemma makes the ticket-title from abbrivation of your dentline, an if its too short, some numbers.
  • !!11einself uses the last 'word' of your dentline and conts the prio from '!'s and ¡Punct from optional 'fyi' or 'idea'

Visualization

To seperate the single categories and their values, i try to use a scheme

  • prio font.color,
  • state background-color
  • punct is mostly a own pictogram (!?)
  • queue underliine for less, Icons for many
  • duedate is selfexplaning
  • user use pix or (gr)avatare

At least I have to seperate these different categories, so id like to use different types. Mainly * for id a monospace * prio in serife an littel bigger * e.g. state in uppercase * queue underliine for less, Icons for many

see also Outermarkdown

Design

Normaly you have lists of tickets, sortet by user, prio, project, date etc, and a singleview for each ticket. In WickeT you only have lists.

Of course the known classical lists like * all for one user * all today * all prio1 * all from one queue

these liste dont include archived tickets (exept a extra view with 'all of one queue with archive')

The normal singleview includes the main description, all the fields and comments. I will try to have a list with all ticketIDs and their references. And this with archive. And you have no commenst, you just add a new "'ticket'" with an punct. and sometimes a person.

The person cans see this comment/ticket in reference to the main ticket in his list, and react. After the person 'archives' only this comment/ticket, so it desapears from his list.

But in the ticketIDsANDreferences liste ist still visible.

Name

The name ''wicketboard'' is a mixture from the words * wik__i * tic__ket(system) * or just wickeT? * combination with 'sheet of paper', 'blade', 'leaf', 'page', 'reed' ....

no, I dont play Cricket with a Wicket, rather I'm little bit wicked and not so good in orthography ;)

But Wicked_Game will be a nice OST ''And I never dreamed that I'd lose somebody like you'', LOL ;) (but I need punk remix for that) * not punk aber zumindest is stone sour (corey) live nahe dran ... [http://www.youtube.com/watch?v=rKGS4we2G2k]