Forum rss-feed

Forum

Software: The Small Things Thread

Most Recent

written by: geert

We've been using a single Jira issue tracker for our projects at work also. Basic on the project a bug is classified into, it's visible to the public or not. We link public issues to internal issues if that's appropriate so that we can keep track of their relationship.

written by: barnone

Mon, 28 Jun 2010 04:23:38 +0100 BST

Starting this thread as a little running list of small things.

When I say small things, I mean software improvements that are probably 1 man day of programmer effort max. A lot of time small things add up to big improvements but this thread is not a place for stuff like, "put a sound engine in the harp", "implement full OSC support." You know what I mean.

First small thing:

1. In AU/VST Configure window (.17) for mapping parameters. When you scroll down and out, it is very hard to know what parameter row you are affecting. Either make the row, column headings sticky to the edges, OR create color variations in the cell background to aid in lining things up.




written by: Tenebrous

Sat, 26 Jun 2010 20:42:39 +0100 BST

RE: #1, and please also make the columns word-wrap, so that you can see more columns in the window - we have a rule at work when doing our GUIs which is to try and make columns fit the width of the data, not the width of the column heading. Doesn't make sense to take up half the window just to show "1". screenshot

Also, it would be great if that window were resizable :)

( btw, this is why I'd love a public Jira-like list of issues, that we can add to ourselves :D )


written by: barnone

Sun, 27 Jun 2010 04:11:39 +0100 BST

+1 on a Jira type bug base. Then users can report stuff, verify the bug for you and also vote stuff up or down.


written by: Tenebrous

Sun, 27 Jun 2010 23:24:21 +0100 BST

Until EigenD goes open-source, I think we may want to look at doing something ourselves for this... only accessible by us instrument owners of course. It'd be interesting to see what others are finding, since we might already have solutions or work arounds for some things, and it'd help avoid sending duplicate bug reports to Eigenlabs too :)


written by: geert

Mon, 28 Jun 2010 04:33:21 +0100 BST

I thought some more about this, I don't mind setting Trac or Mantis up at EigenZone, but I want to avoid what happened with the wiki. Since Eigenlabs opened up their, the EigenZone wiki is basically dead and rightfully so. Since Eigenlabs is going to open up their own installation of Trac once EigenD gets open sourced, the same will happen.

John? Any news in this area?


written by: john

Mon, 28 Jun 2010 08:45:07 +0100 BST


Hi Geert

We already have Trac running which we use to monitor all bugs here, but its not really suitable for public consumption as yet. Maintaining a publicly viewable bug database is actually fraught with a lot of issues (note that Apple do not make theirs public anymore, which is rude but understandable). We're also running a really old version of Trac at the moment (for a bunch of reasons not least of which we customised it a fair bit years ago and we have to reimplement the changes when we upgrade), a version that Jim doesn't think is up to date enough for public use.

All of these are solvable with enough human resource behind it, but since Sam is the only person who triage's bugs right now he would end up maintaining it and I don't want his head to explode, he's been really busy on documentation and setup work recently. I think that we'll probably make bug tracking available to developers only to start with, when we start the open source process off, as this is more manageable. I'm hoping to shake enough resource free to get this done this autumn.

On a related note, the idea that we could vote bugs up and down, while being very appealing, doesn't really fly right now. From a software point of view, the Eigenharp community is divided into two groups of players at the moment, people who are deeply interested in the future development (such as yourselves) and the other (actually larger) group who just want to play and don't care about the software beyond what it does for them right now. From our experience with customer services to date, the things each group regard as significant bugs are really different, and deciding what to work on next is really difficult - do you work on the bug that 'power users' don't care about but that really upsets beginners, of the one that the very vocal community are bothered by? I'm not convinced that a social network style vote will make that decision easier, but please, if you have a good argument, have a go at persuading me!

John


written by: geert

Mon, 28 Jun 2010 09:15:12 +0100 BST

I don't think the voting is particularly interesting either, besides for you to have an easy metric of the issues that are most annoying for a certain group of people.

What sound the most interesting about a public issue tracker is that we can all see what has already been reported by others, add additional comments and not bother you guys with it individually anymore. If there's a temporary workaround or what not, we can then help each other out on there ... and Eigenlabs might once in a while add information also.

It seems to me that this would actually remove a lot of the time that you guys are now spending in support by having to go all this emails individually and replying to us all individually, and so on.

Of course, this issue tracker would only be useful if it's being looked at by Eigenlabs and regularly monitored. If this would just end up being an isolated island of us moaning at each other, there's not much use :-)

I don't mind setting an issue tracker up on EigenZone with the purpose of what I described above. This removes the 'urgency' from you also, meaning that Sam can focus on more important stuff than opening up your internal issue tracker.

What do you think?

Geert


written by: mikemilton

Mon, 28 Jun 2010 09:48:03 +0100 BST

Actually, it might be best to think of this as a support thing rather than a development thing. It is then easier to see a cost benefit as Geert pointed out above and it is clearly a benefit to customers.

Having canned answers to repetitive questions is useful and efficient even if it is internal and they are tweaked for each reply. It could be that the work required to make them (or a subset of them) public would be cost-beneficial.

In any event making this kind of knowledge explicit is really helpful as support staff grows or changes. It is the kind of intellectual capital that small firms often fail to capture but is quite valuable (this is sometimes discovered when it walks out the door or gets run over by a bus)


written by: john

Mon, 28 Jun 2010 11:04:43 +0100 BST

Thanks for the offer Geert. I think that having a separate issue tracker from the one we use here would be too much for us to keep consistent sensibly and I suspect that it would get out of sync with reality pretty quickly as a result. I think this is mostly a human resource issue at Eigenlabs and we definitely don't have the resources to keep up with two issue systems at once.

I'll chat with Jim about what his plans for making our current system more visible are and get back to you when I know more.

BTW, we do normally try and highlight all the main outstanding issues on our tracker in the release notes for each release. Sam maintains this, we could as an interim measure make this more comprehensive if that would be useful.

John


written by: Tenebrous

Mon, 28 Jun 2010 12:56:05 +0100 BST

I wrote a whole lot here ... deleted it though because I think it's all covered above.

I agree that the voting is of no use, pretty much.

Also, I *don't* agree with you Geert - I don't think Eigenlabs should take it on themselves to monitor our list at all. We're trying to reduce their load, after all :)


I was originally thinking just a simple Google document with a darned simple list of minor things, but you can get bug tracker software for free so why not use it. And the official Forum is not the right place for this either.

Personally, I just want a list of issues and a "Has Eigenlabs been told about this? Y/N" thing too. We can discuss those little things amongst ourselves and maybe even help solve them for each other, discuss them, and finally present them to Eigenlabs via email or this forum if we agree it's a bug or that a change would be nice or whatever.

I certainly wouldn't want this 'non-official bug list' to be public as it may very well give the wrong impression. I'd want to feel free to comment on trivial things and not make the 'outside world' feel as though there were a million things wrong and only two or three right.

Tene

PS. I'm really sorry barnone, I seem to have totally derailed your thread ;)


written by: geert

Mon, 28 Jun 2010 13:13:00 +0100 BST

@Tene, the problem is that by doing that we essentially strip information away from Eigenlabs since they don't get a bunch of different emails anymore, indicating the importance for the users. It will just be one email and that's it. If Eigenlabs doesn't monitor the relevant issue in the tracker, they can't tell how many people are actually interested in seeing a particular issue fixed. A lot of them don't really require a discussion, they're merely "X doesn't work when I do Y with Z".


written by: Tenebrous

Mon, 28 Jun 2010 13:37:54 +0100 BST

@Geert, good point there. Unless the person who contacts Eigenlabs includes that info, i.e. "20 people have confirmed this as a bug"...


written by: mikemilton

Mon, 28 Jun 2010 14:34:06 +0100 BST

@Geert - Well, John has (rightly, I think) been clear about their capacity to undertake this so, yes, they won't know. But that is true regardless of where it is started.

@Geert, @tene - I think there is *value* in this sort of thing being community / unofficial because then it is not possible to see it as an eigenlabs forward looking statement. I also like the idea of a *document*


So, I would value a place to look were we could:
- see what we collectively know as 'broken'
- see if someone has already done something I'm trying to do and how
- record things I'm trying to do and, hopefully be told how
- allow bugs and wishlist items to emerge

In some ways, that is one purpose of this forum except that one would not have to search about and a forum lacks the structure of a support DB. Many communities have moderated forums where the moderator extracts this from the discussion to create an 'archive'. I'd happily volunteer to be just such a (co)moderator in a setting such as any of the many group hosting environments.


written by: geert

Mon, 28 Jun 2010 14:41:35 +0100 BST

@Mike, what you explain here could then probably best be documented in the wiki, either the one here or the one on Eigenzone


written by: geert

Mon, 28 Jun 2010 15:48:06 +0100 BST

- double submit, deleted -


written by: mikemilton

Mon, 28 Jun 2010 16:29:51 +0100 BST

@geert. I agree but I suspect that only a low percentage of users will actually *use* a wiki


written by: john

Mon, 28 Jun 2010 16:40:24 +0100 BST

Most bugs actually come in via the built in bug reporter in EigenD or direct email to our support department. I think the solution here is for us to make the tracker public, its the only way I can see of it being consistent - otherwise things could get very very confusing for everyone. We will do this, its just a matter of resources to do it (and if there's one thing I'm learning all over again this year is that if you can't do it well, don't do it at all - this is a great example of this) and soon as we can free someone up to work on it, we will.

I also agree with Mike that we should maintain a feature wishlist. We have a giant one already internally (also in Trac) and this *would* be a great application for a voting system, although given the technical competence of many of our players I am scared of the 'anti vote bot' software we'd have to write!

John


written by: geert

Mon, 28 Jun 2010 16:43:04 +0100 BST

@John, lol about the anti vote bot :-)

Easy fix, only allow one vote per registered serial number of an instrument and check that against the email address of the logged in user that is voting.


written by: Tenebrous

Mon, 28 Jun 2010 17:26:21 +0100 BST

@Geert - I second your lolling... :)

@John - by 'public', you mean 'instrument owners'? Also, you know you have beta testers in us lot even if something isn't totally polished, but I do agree that it's only worth doing if done well... or at least, if there is a *plan* to do it well eventually :)


written by: barnone

Mon, 28 Jun 2010 18:14:51 +0100 BST

@john

Voting bugs up or down doesn't necessarily impact the feature list for customers. What it does do is help verify bugs.

Take a look at the Adobe Flex Jira bug tracker.
http://bugs.adobe.com/flex/

Let's say geert finds and reports a bug. Maybe you guys can't reproduce it and it gets dropped. Now I come along and see geerts bug and say, hey I have the same issue on my machine. I "vote it up" which basically just says, yeah this is really an issue and it affects me too. I go in and add some additional details to the bug that helps eigenlabs and the developers get it fixed. Rather than you guys having to figure out how to assemble all these random reports into the proper bug buckets.

The submission form is OK but in general I may have additional information to add later to the bug. For example, I'm not able to attach images or other data to the automated form.

Once a bug is submitted to you it it enters a blackhole. I have never had further communication about a bug. It would be much more efficient to get a bug # back and be able to track it's status, add additional information etc. Eigenlabs has never asked for more information. That to me indicates that the process could be more efficient about collecting information.

In some cases companies have both internal and external bug bases and externally tracked bugs link to the internal ticket #.

In general "bugs are bugs" and not features. If something is really a bug, then it should be fixed eventually right?



Please log in to join the discussions