TRACKER/FLYSPRAY: When and How to use it

[AISEAG]

Hi,

This action should be pursuited with OpenCPN natural plugin such as :
- Gribs : 12 requests
- Dashboard : 41 requests
- WMM : 3 requests

Nota : 0 request for Chart Downloader

Serge

[rgleason]

We have some progress on number of feature requests. 8 have been closed, however there are still 45 with votes=0 and 105 with vote less than 2!
Few have been voting over these several months. Therefore rather than make a separate category for less than 2 votes, I think the most effective thing to do is to change all such entries into "VERY LOW" Severity which applies a light yellow background. If an item cannot garner more than 1 vote it should not be considered for implementation, unless the OP offers it, and even then it is probably not needed.
Over the next several days we will be making this change to the OpenCPN Feature Requests project list.

Once again, if there is no interest (Votes=0) there is no point in programming it and the item should probably be removed after several months have passed.

If an item has one vote by th OP it should have at least another before even being considered, therefore these will all be labeled light yellow "Very Low" severity.

[rgleason]

There, that did not take long to do from my cell. All Vote=0 Feature Requests have been assigned Low Prioriy and "Very Low" Severity with the exception of 3 items.

So get voting and use your 3 votes per day every day! Vote for your favorite items only.

Tomorrow I'll start changing the Vote=1 items to Very Low Severity too.

If you were a programmer would you bother with Vote=0 items?
How about programming Vote=1 or 2 or 3 items?
We've set a very low bar here and allowed months to pass with adequate notice.

After changing all Vote=1 items to "very low" light yellow we will be culling all old and outdated feature requests.

If you can't vote for it, it does not belong here! Right now we could just reduce the feature requests to about 100 by deleting all 45 vote=0. Easy.

[rgleason]

Sorry, here is a link to Tracker with sort for Votes=0
OpenCPN::OpenCPN00 - OpenCPN - Feature Requests: Tasklist

Tomorrow the list of "unvetted" (less than 5 votes) will become clearer because of the 152 total, only 46 are being considered
OpenCPN::OpenCPN00 - OpenCPN - Feature Requests: Tasklist
(with 2 votes or greater) will be in colors other than light yellow.

I don't think active users will be too happy seeing some of their requests drop in importance, but this needs to be done, the Feature Request list is too long and unrealistic, and it needs greater hierarchy and some realistic requirements.

The only counter to these changes is for all USERS to get VOTING for your requests and other requests that you would like to see implemented. Get voting NOW, you are only given 3 VOTES per DAY!

[rgleason]

I think we are going to need to implement some minimun Vote requirememts to remain on the list because users are not voting.

For a feature request to remain on the list it must have recieved at least 2 votes in 1 month's time otherwise it will be removed and not implemented.

[rgleason]

Serge is there a way to show an inception date in the records?

[rgleason]

We have the "Opened Date". A feature request not gainiing at least 2 votes in one month is subject to removal.

[rgleason]

OpenCPN Feature Requests Vetted > 4 Votes
Total 14 Low-High Severity & Low-High Priority

OpenCPN Feature Requests
Votes 2-4 (47) Low-Medium Severity & Normal Priority
Votes <2 (95) Very Low Severity & Low Priority
Total 142

OpenCPN Programmer Needed, Nice Feature (will not be implemented)
Total 13

------------------
PROCESS

1. Vetted List - 8 Votes will be required when list reaches 20 Tasks.
2. Feature Requests List, Votes=0 & 1, Very Low Severity & Low Priority Items (New Items & Old ones that hang around) -

• Voting is the only way to ensure that these items will remain on the list.
• Feature Requests opened before May 28, 2016 without at least 2 votes by June 28 are subject to Closure or relocation to Programmer Needed, Nice Feature as determined by the administrators.
• New Feature Requests after May 28, 2016 are given one month to gain at least 2 votes, otherwiseare subject to Closure or relocation to Programmer Needed, Nice Feature as determined by the administrators.
• Items in this category have the attention of the developers only in very rare circumstances. They need the enthusiasm and support of the community through VOTING to survive.

1. Voting Suggestions

• You must be registered on Tracker Registration
  
• You must be logged in to Vote Tracker Login
• You are given only 3 Votes per Day.
• Vote Daily first for your Tasks, then for ones you want.
• To view a list of "Tasks I reported"
  • Select "All Projects" from the upper right dropdown list.
  • Select "MySearches" (next to your name).
  • Select "Tasks I reported"
  • A list should appear below, those are your tasks. VOTE FOR THEM.

[fgd3]

Originally Posted by rgleason

If you were a programmer would you bother with Vote=0 items?
How about programming Vote=1 or 2 or 3 items?
We've set a very low bar here and allowed months to pass with adequate notice.

When I was a programmer several decades ago I made it a practice to check items that didn't have a lot of user interest in case (1) they impacted the integrity of the system and (2) they were quick, easy things to fix.

Users were terrible judges of the amount of programming required to effect a change. I was often approached by a user who very apologetically asked if I could find time to change the format of a report (a trivial task) but blithely asked for a basic conceptual change in how the system worked.

Having users vote on features isn't the best way to allocate resources. Many users can't visualize the benefits of a feature until they start using it. Multitasking operating systems--or even systems that allowed rapid task switching--were a really hard sell. Can you imagine trying to work without them now?

Fabbian

[wdkester]

I'm with Fabbian. I think that very few of the users are voting now. I don't think that a 1 month time limit will cause a significant increase in voting.

The following may not be true of all implementers; however, in an opensource environment the implementers are free to implement features that appeal to them. They may get ideas from the list and perhaps some sense of priority; but they are unlikely to implement something they don't agree with or don't like.

I realize that I am being a little provocative, so go ahead and disagree.

[CarCode]

May I remember that nobody wanted the fogging charts and even nobody voted for them they are implemented. So the voting procedure is for nothing...

There are other examples where a stubborn person makes what he wants. There are no democratic rules here.

Gerhard

[rgleason]

Guys, we've got to try to clean house and prioritize somehow.

Programmers do have their own preferences and knowledge, sometimes they need perspective, new ideas, and assist by User Input. Voting is one method, which can work here.

With almost 200 OpenCPN Feature Requests, and a number of them dated back to 2010 and 2011, it became clear that we needed to do something and VOTES is the most User Democratic way to express what we would like to see, in a volunteer army (which may not be "democratic") but at least has many high achievers.

I am OP (Original Person) for about 22 Feature Requests with only one vote -mine, so in a month I am not sure how I'll feel about some of them if one other person has not voted for them. I suppose there are a number of those ideas that could go into the trash bin, or into a category of "Feature Requests that did not make it..." I would not object to a 2 month wait.

Alternatively, did you see how FS#2083 Gpx Easy Import shot up to 13 votes in one week, and is now high on the Vetted list? (Thanks Phillipe).

What I would like to see is an increase in the allowed daily votes to 6, 8 or 10 , so that we could Vote less often, in a 1/2 hour be able to pick out the important ones we would like to have implemented. I have not found a way to change that yet. Also perhaps we could vote twice for an item? Just joking.

We have noticed that the "Vetted list" has grown significantly to 14 in the few weeks we have been making changes. Also, the number of FS missing even one OP Vote has been reduced substantially.

Its your choice to participate or not, but I hope you do, and in the process add some good observations and ideas to the comments as you read the FS and decide to vote for it or not. The good thing is that if you do not participate, the Feature Request list will be culled further.

Gerhard, you should go sailing! You get grumpy, particularly if you've been at the computer too long. So just go sailing and when you come back, you'll feel much better... guaranteed!

[fgd3]

Originally Posted by rgleason

Gerhard, you should go sailing! You get grumpy, particularly if you've been at the computer too long. So just go sailing and when you come back, you'll feel much better... guaranteed!

I think that advice applies to all of us.

I understand it's difficult to prioritize the list of feature requests without some indication of which ones have broader appeal. There's nothing wrong with encouraging folks to show their interest in a feature by voting.

Where I think you've gone wrong is insisting that voting is the only way to allocate resources. In an earlier post on this thread I explained some reasons a programmer might choose to work on an item that didn't have any votes.

It's wrong to assume no one cares about an item because it has no votes. The fact that someone posted the item disproves that. It's too bad the system doesn't create new items with 1 vote from the original poster. If you treat 0 votes as a vote by the original poster there is the risk that those of us who have learned to game the system by going back and voting for our items will get an extra vote. Since so few items get more than 1 vote that could certainly skew the results.

Don't be overly eager to clear items from the list. Items should be closed when they are completed or when a decision has been made that they are bad for the project and won't be implemented. I would hope, for example, that a request to drop support for raster charts because they are old fashioned would be immediately rejected without waiting for any vote count.

Just because other users and even programmers don't see the value of a requested feature doesn't mean it isn't a good idea. It may take a while before someone else sees the benefit and adds their vote. Very likely it will involve some advocacy on this forum to get others to see the benefit.

Bug fixes should be treated differently from feature requests. No votes should be required for a bug fix. If the program isn't performing as it should fixing that should take priority.

So I would suggest you continue soliciting votes for feature requests, but back off on the rhetoric a little bit. Treat votes as a guide to user interest in features but recognize that features without any votes may also have merit. Don't take anything off the list until it is completed or until it has been discussed and agreed to be unworthy of implementation.

Fabbian

[rgleason]

Good points Fabbian. I use my "free" vote for my items. I don't believe votes are need for bugs but if I have seen the problem I will add a vote just so the developers have some idea of how many have noticed the "bug". Its a form of confirmation that is helpful.

I expect delelopers will do as they wish, but lots of votes gives greater credence.

I will back off on retoric when I think enough people know about voting and how to do it. Another advantage is as they read the items they can comment and/or vote. This builds on ideas.

[wdkester]

Maybe, when we add an item to flyspray we need to sell it, it's benefits, how it would be used etc. The submitter should post a discussion under "Feature requests". A lot of the time I either don't understand a request or see a compelling need for it.