Thoughts or design ideas on priorities/tags?

[theonewolf]

Is there any thinking on how to do priorities or tagging inside of tigger?

Or would this detract from the simplicity mantra? I'm OK with sticking to simple :)

[dshipper]

I think the mantra should be "simple yet powerful." So if we can think of a user experience to do tagging/priorities without making things hard to understand we should totally go for it. I know a lot of people wanted to be able to mark off tasks by putting some sort of tag in the commit message the corresponds to a task which would be good to add. I think also being able to tag a task with a persons name could be interesting, and also tag completed tasks with who completed them. I'm totally open to your thoughts, this is a group effort, so what specifically do you want to add? Let's make tigger awesome.

[theonewolf]

No big specific thoughts right now, I was looking for a way to more deeply differentiate say immediate tasks vs long-term rather than just have them listed oldest to newest.

However, I think that since we're building something new here, we have an opportunity to innovate if we want. So like you said, we should think for awhile on this and also get any other input we can and then start designing.

I'll definitely be pondering this over the 4th weekend :)

[dshipper]

Ok awesome I will as well. Let's talk after the fourth and then get to work on some of the features that we've decided on. I think the key point is to keep in mind the core user for something like this. In my mind it's a hacker with a small team who's focused on productivity, and tasks integrated into his workflow.

[dshipper]

I know I said we would talk after the fourth but I fixed the delete issue tonight and I thought I would expand a little more on my thinking. The problem with existing solutions like todo.txt is that they're not focused on collaboration. Tigger's beauty is that you have a simple command-line based manager, like todo.txt, but your tasks can be instantly shared with anyone else just by doing a git push. So I think that we should be concentrating on making collaboration as easy and powerful as possible. Some things I think we should add:

• Make it possible to assign a task to a person.
• Make it possible to "checkout" a task. So if I fire up tigger I can see who on my team is doing what task at any given time.
• Be able to prioritize tasks (a la todo.txt)
• Add better stats reporting - this is just personal. I really want to be able to see more quantitative data on how much I'm getting done on a project at any given time. I think that's something that github doesn't do particularly well that we could expand into.

Some other things to think about:

• We should definitely remove the rubygems dependency. How to do this is much trickier....thoughts?
• Should we stick with C as the language of choice? I wrote it in C originally because that's what Git is written in - but if we're think another language like Python or Ruby is a better fit it might be worth a switch.
• Tigger got sent to a bunch of startups in New York by @scotterc. Some people wanted it to integrate with Pivotal Tracker, but I'm not so sure. Doing that makes it less of a standalone tool and more of just an add-on to Pivotal Tracker.

What are your thoughts? (@scotterc, @sneak feel free to weigh in as well)

[theonewolf]

Replying mostly inline. Not sure what it'll look like on GitHub.

I know I said we would talk after the fourth but I fixed the delete issue tonight and I thought I would expand a little more on my thinking.

It's good being self-motivated. And somehow I'm responding too :p

The problem with existing solutions like todo.txt is that they're not focused on collaboration. Tigger's beauty is that you have a simple command-line based manager, like todo.txt, but your tasks can be instantly shared with anyone else just by doing a git push. So I think that we should be concentrating on making collaboration as easy and powerful as possible.

I basically wanted a managed todo command line just like this for awhile :). The collaboration capability by using a git repository was an excellent choice/side effect.

Some things I think we should add:

• Make it possible to assign a task to a person.

Sounds like a good idea. Seems we could or should piggyback somehow on GitHub users and/or use the git repository author/email/signing system. Not clear exactly how to do it well (how do you know who exists or their proper handle, empty repository case so no prior committers to even look at etc.).

Maybe I'm too complex and a simpler solution is better :p

• Make it possible to "checkout" a task. So if I fire up tigger I can see who on my team is doing what task at any given time.

This could be built with an assign task mechanism, or vice versa. I mean internally the code would be the same or very similar. Checkout assigns and assigning is "forced checkout."

• Be able to prioritize tasks (a la todo.txt)

Yes, I'd like this too and I imagine it would cause reordering of tasks (perhaps a priority queue data structure, maybe overkill), as well as color coding them differently.

As far as color goes, I think we should expose a configuration file for color scheme. I offer to do this.

• Add better stats reporting - this is just personal. I really want to be able to see more quantitative data on how much I'm getting done on a project at any given time. I think that's something that github doesn't do particularly well that we could expand into.

Not sure what stats we're looking for here. We could have time to complete tasks. Maybe some way of starting a task/that timer (current working task, changes view of tasks etc).

Some other things to think about:

• We should definitely remove the rubygems dependency. How to do this is much trickier....thoughts?

I wasn't sure what the ruby gem was doing, I can figure that out though. I am also 100% happier if it is removed. I'm thinking it shouldn't be hard to get rid of, but I'm speaking before I know exactly what it does.

• Should we stick with C as the language of choice? I wrote it in C originally because that's what Git is written in - but if we're think another language like Python or Ruby is a better fit it might be worth a switch.

I would vote for Python if a switch is needed because I love it. That said, I also love C. I am in favor of keeping the tool in C. This depends a bit on how many features we want to add and how rapidly. I think a core has appeared in the C and we can hone it into something fairly polished.

Personally I really like efficient standalone projects (little to no external dependencies a huge plus) written in tight C.

• Tigger got sent to a bunch of startups in New York by @scotterc. Some people wanted it to integrate with Pivotal Tracker, but I'm not so sure. Doing that makes it less of a standalone tool and more of just an add-on to Pivotal Tracker.

I think the best thing to do here is to expose a tigger API for plug-ins.

Let anyone that wants to write a plug-in integrating tigger with their favorite system do it and contribute or release as a third-party binary. This is where licensing becomes a bit important for being clear on.

1) it's good engineering

2) it makes other people that know the tracker system in question better do the work

3) everyone can be happy

Your observation that tying to Pivotal is bad is exactly correct. Plug-ins sidestep the problem by enabling integration without loss of generality.

So we can integrate Pivotal. And JIRA. And Bugzilla. And Lighthouse...etc etc

[dshipper]

I'm surprised/excited that you responded so quickly :) I loved your thoughts. The rubygems dependency installs Grit which is used by the Tigger script that checks off tasks based on the user's commit messages. Here are what I think some of the takeaways are:

1. Let's stick with C.
2. Let's definitely do an API that's a great call. I'm not exactly sure how to do this though.
3. It's time to pick a license (I'll go through a few and make a decision tomorrow).
4. Let's decide what features each of us wants to work on. What are you most excited about doing/adding?

[theonewolf]

I'm surprised/excited that you responded so quickly :) I loved your thoughts. The rubygems dependency installs Grit which is used by the Tigger script that checks off tasks based on the user's commit messages.

Interesting on the dependency, I'm wondering if it is doing fuzzy matching or anything advanced.

Are the ways a task can be recognized defined? Is it just the full task message character for character?

Maybe we can create a documentation page on GitHub for that spec.

Here are what I think some of the takeaways are:

1. Let's stick with C.

Yeah, just keep the momentum for now :)

1. Let's definitely do an API that's a great call. I'm not exactly sure how to do this though.

I can work on this for a first cut. I also think this would be a good thing to create a GitHub page for to describe the API for comments.

For this it's probably best to iterate (propose API, get comments, rework etc). Probably having a demo plugin for Pivotal would be a good sea to exercise the API as well.

1. It's time to pick a license (I'll go through a few and make a decision tomorrow).

Sounds good :)

Maybe also create a mailing list on Google Groups? Just a thought.

1. Let's decide what features each of us wants to work on. What are you most excited about doing/adding?

I can do the refactoring of color decisions into an external config file.

Also the API for plugins.

[theonewolf]

Wanted to add some fun references for SW Dev:

http://www.aosabook.org/en/index.html

The Architecture of Open Source Applications

Free book by volunteers from the various communities.

http://nostarch.com/growingsoftware.htm

Growing Software My favorite publisher No Starch Press :p

A study on leading successful software development teams / companies

http://www.zeromq.org/

A very successful open source community

More just a reference for what things work well in growing communities and letting people take part in processes

[sneak]

I've actually never used your project.

I just clicked in from HN and GitHub makes it too easy to submit a pull request with the web text editor, and your makefile needed help.

Now that I've reviewed it a bit, it seems to me that you're reinventing Taskwarrior to some extent.

http://taskwarrior.org/projects/show/taskwarrior

[dshipper]

I saw TaskWarrior from HN actually and it seems like a cool tool. What separates Tigger to me is our commitment to a simple, powerful user experience that integrates into individual and team workflow seamlessly with Git and Github.

If you're not enthused with the project that's totally cool, we'll just keep working away on our corner of the web :)

[theonewolf]

I agree that there's room to differentiate :) Probably some good inspiration/lessons can come from TaskWarrior.

[dshipper]

@theonewolf Awesome I'm glad we're together on this:)

So in response to your earlier message, tasks are recognized simply by going through each task in the .tigger file and each commit message and then seeing if any substring of any commit message matches the task string.

If you're thinking about working on the getting rid of dependencies, the API, and making colors configurable I'll attack some of the other stuff on our list like assigning, checking out, and prioritizing tasks. I'm also going to spend some time reading those links on how the hell to manage a project like this :) thanks for sending them over. And definitely tell me when I'm being stupid about something, or missing something that we should be doing it's my first crack at an OSS project.

Happy Fourth :)

[theonewolf]

@theonewolf Awesome I'm glad we're together on this:)

:)

So in response to your earlier message, tasks are recognized simply by going through each task in the .tigger file and each commit message and then seeing if any substring of any commit message matches the task string.

Yes, I read through the Ruby myself. I'd rather see some approximate matching algorithm in the future, also support for finishing tasks by referencing them by # or some unique tigger ID (we might want to have specific task IDs separate from their display order).

If you're thinking about working on the getting rid of dependencies, the API, and making colors configurable I'll attack some of the other stuff on our list like assigning, checking out, and prioritizing tasks. I'm also going to spend some time reading those links on how the hell to manage a project like this :) thanks for sending them over. And definitely tell me when I'm being stupid about something, or missing something that we should be doing it's my first crack at an OSS project.

Sounds like a pretty good split, we can just focus on what we're good at for now depending on skillsets.

[dshipper]

Yes we should definitely implement finishing task by some sort of ID number. Cool I think we have a good amount of stuff to work on and a clear direction so I'l close this issue for now and we can reopen once we get through this list.

[theonewolf]

Yes we should definitely implement finishing task by some sort of ID number. Cool I think we have a good amount of stuff to work on and a clear direction so I'l close this issue for now and we can reopen once we get through this list.

Sounds good to me.