I'm a lazy person. I always try to go the path of least resistance. I beg to notice that "least resistance" doesn't equal to "no resistance", but that's picky.
Anyhow. I'm partly glad that I chose Assembla (crap, I never remember the name). It has all kinds of tools that Google Code simply doesn't provide. But it's a bit messy with its features. Assembla has issues, tasks and a wiki. Now, if I think of something that I want to be done, it's a bit of a puzzle to know where to put it. It would be easy if the wiki would be reserved for brainstorming, issues are for reporting when something goes wrong and needs fixing, and tasks are just stuff to do. But it's not like that. Tasks are stripped issues, and always are associated with a milestone. Issues accept a markup language (think BBCode), but tasks don't. Tasks are easily marked and saved as 'complete' just by ticking a box, which makes tasks seem "light" and not noteworthy. Issues are commented upon, as tasks are replied to. Additionally, tasks are displayed in a "Flow"-section, which I think is supposed to be a list of various message. If you create a new entry in the Flow-section, you create just a message for others to read, with no magic abilities. Also, tasks don't seem to count towards milestone completion, only issues...
In a word, it needs getting used to.
Subscribe to:
Post Comments (Atom)
Posts
2 comments:
I am the creator of the Assembla system, and I also have struggled with what to do with the Milestones feature.
Milestones is confusing because it is a combination of two workflows (flow/tasks, and tickets) for two user groups (non-programmers, and programmers).
We need the Milestones list because we use it in the Tickets tool to sort development tickets into releases or iterations. That is conceptually simple. The problem arose when we noticed how people were using this. A lot of them were using Basecamp for non-technical work, where they became very used to the Milestone / Todo format. We needed a way to link this to the work of the development team - the tickets. So, we added the "task" items to the milestones and we made it look like a basecamp-style to-do list. In order to avoid adding yet more alerts and objects, we adapted our flow messages to serve as "tasks".
So, what are the options to fix this crossed wire?
1) We could just kill the task feature on milestones. This will make Milestones a much simpler feature, used to track development tickets.
I think the Flow (message) issue/priority format is actually a more effective workflow for tasks. It's lightweight and the priority view tells you what you need to know. But, it doesn't look like Basecamp and other familiar tools.
2) Separate tasks from flow items and make them just like Basecamp to-do's. So, now we have another type of object to manage, albeit a simple one. This raises the question of whether we give people a new class of email alerts (Tasks) to turn on and off. Or, do we just strip this feature down and remove alerts and comments.
Which would you prefer?
Markup format is Textile. We might offer a WYSIWYG editor if there is demand for it.
I feel a bit honored about this comment, being the first one on the whole blog, and it coming from the Assembla founder makes it even more awesome.
But, before giving you some sort of an answer, I feel it necessary to put my developing experience into context:
LightFrame is by far the most encompassing project I've started or even been a part of. In fact, I'm starting my very first ever software engineer job tomorrow. Collaboration software is a somewhat uncharted territory for me, so I am absolutely no authority when it comes to doing stuff "right". I just know how I feel about the stuff I'm using, so that's the only thing I can go with.
Also, I've never tried Basecamp, only Google Code (nice features, those that exist, and smooth usage) and JIRA (can't exactly remember, other than it felt clunky and counter-intuitive) before Assembla. Additionally, I've only used Assembla for a few days, so I'm not too trained in what Assembla is actually capable of doing, and how to get the most out of it.
When it comes to fixing this conundrum, I don't feel that you would be in a either-or situation, not with those options at least. I could easily see a third option: enhancing tasks, making more like issues feature-wise, but keeping them separate semantically - issues have to do with existing work, and their problems, as tasks are stuff that need implementation. Issues come from both inside the project and from the community (if any), while tasks can only be applied from inside the project (as it would be silly for an outsider to command a developer to do anything). There's no reason to integrate tasks to the Flow, with a stripped-down version of the message, if that's wanted. I'm not going to give you a 'definite answer', because I don't have one.
The problem that I have with issues/tasks is what I described above: I would like to separate tasks from issues, but still both behaving the same. Maybe even keeping tasks hidden (if wanted) from non-developers, as an internal development plan. Tasks could even be later on broken into smaller issues, that need to be fixed. I don't know.
But, while I'm at it, I would like to give do some specific feature requests that I find wanting. In a space's Issues-tab, one has the ability to list the issues according to certain criteria. I like the "Active by Milestone" view, which is quite descriptive. But I'd like to have the individual issues to be further sorted according to priority. While the colors are handy, I haven't gotten used to them in an intuitive way. I might some day, but I'd rather concentrate on my project, than learning how to interpret the supporting software (Assembla).
I can see it feasible to have an issue accepted, but unassigned to any specific person. This would differentiate between "we haven't processed this issue yet" and "we're aware of this issue, and have agreed that it indeed is an issue, but nobody has started thinking about it yet".
Also, when getting HTML formatted email from individual issue changes (I'm not sure why I even got HTML formatted, as I remember that I configured everything to be sent as plaintext), the Textile markup is showed in the HTML, instead of having the HTML styled as in the ticket itself.
Ah, something more, which most probably is out of your hands, having capital characters in a header ("h1. FUBAR this is") makes the header render weirdly, due to added caps-span.
Despite the stuff above, if you really have written Assembla all by yourself, I feel compelled to tip my proverbial hat. It's a large project, and everything taken account, it's very well made. Thank you for the service!
Post a Comment