Keeping track on feature requests and bug reports

I'm having a hard time keeping track on the various feature requests and bug reports in this forum. And I'm very likely not the only one.

We see many requests and issues where the Monkey team - and in particular HAWKEN - replies that this or that is (now) on the internal to do list (or whatever) - and thanks for that.

But... then we don't hear any more about it... May be it will show up in some future release - may be not. In the former case, we can be happy when we see it, in the later we don't know if the feature is just delayed, if it is postponed, if it is out-of-scope (according to product management) or something else. Even if we see a particular feature in a future release, we cannot be sure that the new feature really is optimal as there are no way anybody can "add to" the discussion or describe new use cases...

I think the Monkey team is doing a great job, but it is almost impossibly to sync the internal and external expectations via a forum as it exists today.

And it would be ever so nice to know what will actually happen with the platform/SDK before we see an release so we can start thinking about the consequences for our existing or future applications before the release.

I have participated in the development of Eclipse for the last 12 years and there we use bugzilla for everything: bugs, features, plans, designs, ... everything. And it works, as it allows everybody to have complete visibility into all issues and allows everybody a voice in designs and plans.

This doesn't mean that you (Garmin/Connect IQ team) should not have the final word on what goes into the platform/SDK - of cause you do - but it means we will know the state of the issues that are important to us. And we can add to issues, if we have alternatives or new use cases that could be relevant to the development. You can even easily state the intended target release for the various features/bug fixes - you should just specify that the target release is an intent, not a commitment! (This is how we do it in Eclipse).

I think something a kind to this will have many big advantages for Connect IQ:

the app developers will feel much more involved and committed to the platform if they get a say in the priorities and designs
you get to tap into a huge mindshare of the people that actually use your SDK - why they want this or that and how it should be used
you get a way to validate your designs with the users of the SDK before you commit resources
we all get to know when something can be expected or why you will not address a particular issue
we all get a huge knowledge base where we can search for solutions and work-around for the issues we have faced without having to restate the issue on the forum again and again
it will level the field as all app developers will have access to the same information

All in all, I see this as a way to ease your work as well as our work!

ruperthawkes over 10 years ago

+1. Yes please.

Former Member over 10 years ago

I also think this is a good idea. Even if its closed source it's still good to be able to submit bugs and view their status. So +1. Crowdsourcing feature requests will also make the platform even more popular. When i heard about connect iq it was an obvious choice to get on the bandwagon. With the upcoming slew of Android Wear based fitness watches that are about to come along that has open development i hope that Garmin can be even more open and Connect IQ is stepping in the right direction. I would not be surprised if Garmin is in fact experimenting with an Android Wear fitness watch. The connect iq initiative is great both for everybody and the more open it can be the better it is for all .. even Garmin. In my personal opinion i would have liked to see a familiar programming or scripting language instead of monkey c . It could even have been a strict subset of some language. Using languages that people already know would make the platform even more approachable.

Monkey C is not a problem for me but if i could have used JavaScript for example or a subset of it i could have used existing code right out of the box and also used existing javascript tools such as linters or unit testing tools. I don't know if monkey c was chosen to lock developers in to the platform or if there was some technical reason but within a couple of years Android Wear fitness watches will probably attract more developers since its an open platform. I think Garmin would benefit a lot for making Connect IQ platform as open as possible to be able to compete in the future. Im really happy with my 920xt and im thankful for Garmin for introducing a development app based platform. Would love to see it even more open and looking forward to be part of it as the tools mature.

hawken over 10 years ago

@TONNY.MADSEN There has been some discussion about an externally-facing bug reporting and tracking system, but right now there aren't any plans to do this that I am aware of.

I completely understand your position. For example, I have administered Hudson/Jenkins continuous integration severs in the past, and having access to their bug tracker saved me a lot of headache on several occasions. The difference is that projects like Eclipse and Jenkins are open source whereas we are developing a closed-source project, as you mentioned.

We use a bug tracking system internally and I've been tagging forum posts to track which threads have been responded to, which require responses, which have reported issues, etc. I plan to regularly review issues related to forums threads and update the thread when the fix or feature addition has been released.

tonny.madsen over 10 years ago

@HAWKEN Whether you have an open source project or a closed source commercial application, does not matter here. In both cases, you need project management for the project that will prioritise and decide on release schedules and the primary difference is that for an open source project the management is usually chosen by merits and for commercial applications, the management is by ownership.