Tracker: call for your opinions

Dear EAP'er,

There is one important issue we would like to have your opinions about: our tracker. Quite some time ago we came to the state where our current situation with the tracker simply does not solve the task it was created for. There are a few issues:

- the amount of poorly processed issues exceeds our abilities to process them efficiently
- the priorities assigned to requests do not reflect their real values, nor contain submitter-specific severity attributes
- a lot of old requests that migrate from version to version with no actions takes
- quite a lot of duplicate requests that aren't marked such
- a lot of obsolete requests not processed in time
- a lot of "To be Discussed" requests that have to be sorted out
- there are many more issues that you are aware of yourself and I did not want to bring here...

So, what we would like to do is to review (and reset) the request database somehow that it becomes usable in the process of providing the best service to our community, customers and teams. Thus, the solution that could possibly work is to allow some time, say 1 month, for you to mark all the requests you consider important and later they will be transferred to the new database. We guarantee that all such requests will be correctly reviewed, planned, etc but we need this help from you in reducing the total number. There are just too many of them to handle, I hope you understand.

Please let us know what you think about it, whatever your opinion is.

Best regards,

Eugene Belyaev
President, CTO
JetBrains, Inc
http://www.jetbrains.com

"Develop with pleasure!"

31 comments

I like the IDEA. Each submitter will mark their own requests which they still consider worth paying attention to, and after a month you wipe out everything that isn't marked as such. As an example, I have 49 open issues (Submitted, Open or To be discussed) under my account, and I think that I would keep just 10 or so.

There's still one thing that this solution doesn't take care of: duplicates. I don't know if some of these 49 issues are actually duplicates of some other issues. Of course, I took care of searching for similar problems when I filed the requests, but I might have missed some. Anyway, with a smaller request database, it will be easier for you to search for duplicates and mark them as such.

So, wrapping up: +1

0

Exactly, we will perform the correct duplicate analysis ourselves, given that we know exactly which requests are going to stay there and which are not.

Best regards,

Eugene Belyaev
President, CTO
JetBrains, Inc
http://www.jetbrains.com

"Develop with pleasure!"

I like the IDEA. Each submitter will mark their own requests which
they still consider worth paying attention to, and after a month you
wipe out everything that isn't marked as such. As an example, I have
49 open issues (Submitted, Open or To be discussed) under my account,
and I think that I would keep just 10 or so.

There's still one thing that this solution doesn't take care of:
duplicates. I don't know if some of these 49 issues are actually
duplicates of some other issues. Of course, I took care of searching
for similar problems when I filed the requests, but I might have
missed some. Anyway, with a smaller request database, it will be
easier for you to search for duplicates and mark them as such.

So, wrapping up: +1


0

Do you have any plans to prevent this new database from degrading to the same state the current one is in?

Bas

0

Well, first of all do not forget that it took almost 4 years to be there were we are now :) It is hard to tell, but this is something we are striving to do in the first place: revive the manageable process. Do you have any other solutions in mind?

Best regards,

Eugene Belyaev
President, CTO
JetBrains, Inc
http://www.jetbrains.com

"Develop with pleasure!"

Do you have any plans to prevent this new database from degrading to
the same state the current one is in?

Bas


0

You could request more help from the community. A few members already post comments in SCR's if they think it's duplicate or already implemented. Maybe that process can be expanded and formalized.
Even if you don't do that, I'm happy you're planning to improve matters, too many good requests are being ignored lately.

Thanks,
Bas

0

I agree that this needs to be cleaned up, but I have a few questions:

1) How do I indicate which of my requests I do not care about, or rather
I should mark which ones I do care about. That way requests made by
people that are no longer around are given less of a priority.

2) Is there going to be a different system? This one leads to a lot of
duplicates and a general degradation of the data. How about adding
characteristics to the items so we can search by category. An example
is if I have trouble starting webapps using Tomcat 5.0.28, I would go to
J2EE, tomcat integration, problems starting or something like that.

Norris Shelton
Sun Certified Java Programmer




Eugene Belyaev wrote:

>Dear EAP'er,
>
>There is one important issue we would like to have your opinions about: our tracker. Quite some time ago we came to the state where our current situation with the tracker simply does not solve the task it was created for. There are a few issues:
>
>- the amount of poorly processed issues exceeds our abilities to process them efficiently
>- the priorities assigned to requests do not reflect their real values, nor contain submitter-specific severity attributes
>- a lot of old requests that migrate from version to version with no actions takes
>- quite a lot of duplicate requests that aren't marked such
>- a lot of obsolete requests not processed in time
>- a lot of "To be Discussed" requests that have to be sorted out
>- there are many more issues that you are aware of yourself and I did not want to bring here...
>
>So, what we would like to do is to review (and reset) the request database somehow that it becomes usable in the process of providing the best service to our community, customers and teams. Thus, the solution that could possibly work is to allow some time, say 1 month, for you to mark all the requests you consider important and later they will be transferred to the new database. We guarantee that all such requests will be correctly reviewed, planned, etc but we need this help from you in reducing the total number. There are just too many of them to handle, I hope you understand.
>
>Please let us know what you think about it, whatever your opinion is.
>
>Best regards,
>
>Eugene Belyaev
>President, CTO
>JetBrains, Inc
>http://www.jetbrains.com
>
>"Develop with pleasure!"

>

0


A good idea, and sadly necessary given the current state of the Tracker. It will eventually degrade, however, if you guys aren't proactive about assigning "Submitted" issues, having the "Planned for" change as your planning does, marking things as "Fixed" when you fix them, and (most important) having tracker items for all items that are actually going into each release, even if you thought of them rather than us. If the product wasn't already so awe-inspiring that it's flaws and gaps were mostly hidden by the blinding glare of it's quality, you guys would be having real problems with your issue tracking...

All that said, I'm certainly willing to review my outstanding requests, and add any annotations or amplifications you want. I've got about thirty issues, most of them slight extensions and "that would be nice" level suggestions.

--Dave Griffith

0

One more thing. I would like to look at the open requests I didn't submit, and annotate them if I feel they are worthy of carrying over. That way good requests from inactive members won't fall through the cracks.

--Dave Griffith

0

Regarding marking your requests: we can add a feature to our tracker that will allow anyone mark a request as valid to be transfered to the new database.

We are actually thinking of migrating to JIRA (but are not fixed with this one) for a large number of reasons (if you would like to know those reasons, this is a topic for a different discussion, let's not discuss it in this thread).

Best regards,

Eugene Belyaev
President, CTO
JetBrains, Inc
http://www.jetbrains.com

"Develop with pleasure!"

I agree that this needs to be cleaned up, but I have a few questions:

1) How do I indicate which of my requests I do not care about, or
rather I should mark which ones I do care about. That way requests
made by people that are no longer around are given less of a
priority.

2) Is there going to be a different system? This one leads to a lot
of duplicates and a general degradation of the data. How about
adding characteristics to the items so we can search by category. An
example is if I have trouble starting webapps using Tomcat 5.0.28, I
would go to J2EE, tomcat integration, problems starting or something
like that.

Norris Shelton
Sun Certified Java Programmer
Eugene Belyaev wrote:

>> Dear EAP'er,
>>
>> There is one important issue we would like to have your opinions
>> about: our tracker. Quite some time ago we came to the state where
>> our current situation with the tracker simply does not solve the task
>> it was created for. There are a few issues:
>>
>> - the amount of poorly processed issues exceeds our abilities to
>> process them efficiently
>>
>> - the priorities assigned to requests do not reflect their real
>> values, nor contain submitter-specific severity attributes
>>
>> - a lot of old requests that migrate from version to version with no
>> actions takes
>>
>> - quite a lot of duplicate requests that aren't marked such
>>
>> - a lot of obsolete requests not processed in time
>>
>> - a lot of "To be Discussed" requests that have to be sorted out
>>
>> - there are many more issues that you are aware of yourself and I did
>> not want to bring here...
>>
>> So, what we would like to do is to review (and reset) the request
>> database somehow that it becomes usable in the process of providing
>> the best service to our community, customers and teams. Thus, the
>> solution that could possibly work is to allow some time, say 1 month,
>> for you to mark all the requests you consider important and later
>> they will be transferred to the new database. We guarantee that all
>> such requests will be correctly reviewed, planned, etc but we need
>> this help from you in reducing the total number. There are just too
>> many of them to handle, I hope you understand.
>>
>> Please let us know what you think about it, whatever your opinion is.
>>
>> Best regards,
>>
>> Eugene Belyaev
>> President, CTO
>> JetBrains, Inc
>> http://www.jetbrains.com
>> "Develop with pleasure!"
>>

0

That works for me.

You could always automate this "mark and sweep" approach every few months - maybe send emails back out to the original posters and if they still want them in there, they acknowledge the email, otherwise the issues will get dropped.

So its a small additional load on the EAP users - as it stands now, I would bet that a lot of people using the EAP builds dont have licenses, hence are getting a great editor free of charge - the "cost" of replying to a few emails every couple of months is not a lot to ask.

JM2C.

Nick

0

Eugene Belyaev wrote:

>Regarding marking your requests: we can add a feature to our tracker that will allow anyone mark a request as valid to be transfered to the new database.
>

>

What about adding 3 buttons to ITN threads, only actionable by the
thread poster:



, with
red : please forget I ever suggested that
orange: I'm not sure, what do you think?
green: I still think it would be useful/valuable


Alain

0

Alain,

Actually, that is exactly how I was thinking about implementing that.

Best regards,

Eugene Belyaev
President, CTO
JetBrains, Inc
http://www.jetbrains.com

"Develop with pleasure!"

Eugene Belyaev wrote:

>> Regarding marking your requests: we can add a feature to our tracker
>> that will allow anyone mark a request as valid to be transfered to
>> the new database.
>>

What about adding 3 buttons to ITN threads, only actionable by the
thread poster:



, with
red : please forget I ever suggested that
orange: I'm not sure, what do you think?
green: I still think it would be useful/valuable
Alain


0

Eugene Belyaev wrote:

>Actually, that is exactly how I was thinking about implementing that.
>

>


1/
Please make sure it's also available, as an additional column, in the
search page (1 line per thread), rather than having us zoom into the
thread to reach the buttons. This would allow us to clean up dozens of
messages in no time.


2/
For some requests, I'd like a SHORT comment area, to plead my case one
last time, or summarize the big picture in 2 lines.

ex:
"This feature makes a lot of sense if you implement
http://wxxxxxx/req123."

or
"The big picture is made of 4 related requests : http:// xxxx1,
http:// xxxx2, http:// xxx3"


Alain

0

Nick Pratt wrote:

So its a small additional load on the EAP users - as it stands now, I would bet that a lot of people using the EAP builds dont have licenses, hence are getting a great editor free of charge - the "cost" of replying to a few emails every couple of months is not a lot to ask.


This and a previous post make a very good point IMO: There is a large
'distributed resource', the EAP users, that is underutilized and is a
good candidate for reducing IDEA developer book-keeping workload. As an
example, the thing that makes successful wikis so successful is that
there are many users who maintain it and keep it organized (see
http://en.wikipedia.org/ for an excellent example).
Finding ways to 'offload' non-automatable tasks to distributed users I
think is the best strategy for solving this recurring problem.
Other possibilities:
- Allow trusted users to organize SCRs into related groups, which can be
browsed
- Revamp the voting system so that it is easy to find items that
really matter, not just have a few loud lobbyists. Something like the
JRating idea would work.
- Have a more unified user forum, possibly wiki-like, which allows
topics to self-organize and bubble to the top. The current wiki is
pretty static (mostly plugin stuff), and not the greatest in terms of
usability. Most discussions are done on newsgroups and SCRs, which don't
'capture' information as well as a wiki-like discussion.

The main point is that our current approach is ad-hoc, rather than
systematic. When we have a problem, we have an informal poll (like this
thread), then interest dies and it is forgotten. We need a more dynamic,
self-renewing, self-moderating approach to user feedback.

--
Rob Harwood
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

0

You could do this by posting another comment. I did that to one of mine
today.

Norris Shelton
Sun Certified Java Programmer




Alain Ravet wrote:

Eugene Belyaev wrote:

>
>> Actually, that is exactly how I was thinking about implementing that.
>>
>>
>>
>
>

1/
Please make sure it's also available, as an additional column, in the
search page (1 line per thread), rather than having us zoom into the
thread to reach the buttons. This would allow us to clean up dozens of
messages in no time.

>
>

2/
For some requests, I'd like a SHORT comment area, to plead my case one
last time, or summarize the big picture in 2 lines.

>

ex:
"This feature makes a lot of sense if you implement
http://wxxxxxx/req123."

>

or
"The big picture is made of 4 related requests : http:// xxxx1,
http:// xxxx2, http:// xxx3"

>
>

Alain

0

Norris Shelton wrote:

2) Is there going to be a different system? This one leads to a lot of
duplicates and a general degradation of the data. How about adding
characteristics to the items so we can search by category. An example
is if I have trouble starting webapps using Tomcat 5.0.28, I would go to
J2EE, tomcat integration, problems starting or something like that.


I note Fabrique is using JIRA ( http://www.jetbrains.net/jira ) for its
bug tracking. Will IDEA make the switch to using JIRA as well at all?

JIRA supports the full contingent of sub categories, and now in the soon
to be released JIRA 3 sub-isses which is very handy.

Mark

0

Will IDEA make the switch to using JIRA as well at all?


Eugene said they where thinking on it.

JIRA supports the full contingent of sub categories, and now in the
soon to be released JIRA 3 sub-isses which is very handy.



I like the newsgroups feed, and I've seen it mentioned that JIRA doesn't support it.

On the other hand, categories are a great advance and if if JIRA has a better search engine it will greatly simplify bug/feature tracking.

0

Carlos Costa e Silva wrote:

I like the newsgroups feed, and I've seen it mentioned that JIRA doesn't support it.


Not out of the box, but would be easy to implement. JIRA already
supports "sent to email, comment via email", all that needs to be
implemented are the appropriate listeners to "post to usenet", and a
process which checks replies coming in to "post comments from usenet".

THe post to usenet is simple, the read/comment a little harder, but
nothing really difficult...

0

Since you threw it out there. Of course I would like to know what the large number of reasons are. Find a home for the thread and I will read it.

0

In article <ck68lk$d4j$1@is.intellij.net>,
Eugene Belyaev <beg@jetbrains.com> wrote:

So, what we would like to do is to review (and reset) the request database
somehow that it becomes usable in the process of providing the best service
to our community, customers and teams. Thus, the solution that could
possibly work is to allow some time, say 1 month, for you to mark all the
requests you consider important and later they will be transferred to the new
database.


How about having one tracker database per release? So everything in
there now would be marked as being for the 4.5 release. If I want a
feature to be considered for the 5.0 release, I'd have to go to the 4.5
release features, find my request, and click something to get it moved
to the 5.0 DB.

Also, I think managment might be easier if a bug/feature could be marked
with one or more topics (like "cvs", "refactoring", "compiler", etc.).


Erik Hanson

0

I completely agree with Rob.
The idea of turning part of the management (dup detection, categorization) to some dedicated EAPers make a lot of sense and was proposed a long time ago.
Offer that and a tool that allows that kind of organizational power associated with powerful search would make IDEA "tracker" a lot more usable (JIRA + Confluence?).

Anyway back on the original topic of this thread, I applaud the initiative. Alain's suggestion makes a lot of sense as usual. I would echo Dave's suggestion to be able to mark others SCRs as well not just because the author might not care anymore but because a lot of good requests were submitted by people smarter than me and I want to make sure they make the cut ;)

Jacques

0

Do any of the tools (JB tracker, Jira, ...) offer other than
HTML-based access? I mean an offline tool that would allow
at least create new reports and respond to existing ones while
not being connected and then transfer it when connected.

thx
r.

Jacques Morel wrote:

I completely agree with Rob. The idea of turning part of the management (dup
detection, categorization) to some dedicated EAPers make a lot of sense and
was proposed a long time ago. Offer that and a tool that allows that kind of
organizational power associated with powerful search would make IDEA
"tracker" a lot more usable (JIRA + Confluence?).

Anyway back on the original topic of this thread, I applaud the initiative.
Alain's suggestion makes a lot of sense as usual. I would echo Dave's
suggestion to be able to mark others SCRs as well not just because the author
might not care anymore but because a lot of good requests were submitted by
people smarter than me and I want to make sure they make the cut ;)

Jacques

0

I agree. I think there should be some "voting" capacity for someone who did
not post an issue,
but voted for it. Question: what percentage of issues currently have votes
on them?
If it is not too large, perhaps you could retain all issues with votes.

"Dave Griffith" <dave.griffith@cnn.com> wrote in message
news:21288765.1097249448048.JavaMail.itn@is.intellij.net...

One more thing. I would like to look at the open requests I didn't
submit, and annotate them if I feel they are worthy of carrying over.
That way good requests from inactive members won't fall through the
cracks.

>

--Dave Griffith



0

Not sure this is different than just targeting an issue for a specific release.

Erik Hanson wrote:

In article <ck68lk$d4j$1@is.intellij.net>,
Eugene Belyaev <beg@jetbrains.com> wrote:

>>So, what we would like to do is to review (and reset) the request database
>>somehow that it becomes usable in the process of providing the best service
>>to our community, customers and teams. Thus, the solution that could
>>possibly work is to allow some time, say 1 month, for you to mark all the
>>requests you consider important and later they will be transferred to the new
>>database.


How about having one tracker database per release? So everything in
there now would be marked as being for the 4.5 release. If I want a
feature to be considered for the 5.0 release, I'd have to go to the 4.5
release features, find my request, and click something to get it moved
to the 5.0 DB.

Also, I think managment might be easier if a bug/feature could be marked
with one or more topics (like "cvs", "refactoring", "compiler", etc.).


Erik Hanson


--

Erb

==============================================================
"Most of you are familiar with the virtues of a programmer.
There are three, of course: laziness, impatience, and hubris."
- Larry Wall
==============================================================

0

Eugene,

thank you for adressing this issue. Using the tracker has become a pain over the ]]>.

I'd like to suggest that:
- you send out an e-mail to all registered EAP users with all tracker request that have been filed by them, maybe in the following order:
1. open issues
2. issues to be discussed
3. issues that were duplicate/do not fix
4. issues that were already fixed
For convenience a link should be included for every issue.
Ask your users to review their open/to be discussed issues and provide a way to transfer an issue to the new database. Maybe something like: Transfer as high priority, transfer as important but I can live without and transfer as "fix whenever you feel bored".

However, maybe you can keep that option available for a long time so that everybody has the chance to review his issues (that is, substantially longer than 1 month).

Best,

Dirk Dittert

0

Oh, one more thing I'd like to see:
Categories for issues that is something like a category for UI bugs (maybe even one for typos that are quick to fix and one for real problems), operating system, ...

Best,

Dirk Dittert

0

I think this is a great idea. Mozilla uses volunteers for what they call QA, just filtering through new bugs and marking duplicates and things like that, and it works pretty well.

0

Erb wrote:

If it is not too large, perhaps you could retain all issues with votes.


Yep, at least take a closer look at those with votes assigned to them, i.e.
don't throw them away blindly if their "owner" doesn't mark them as a still
relevant issue.

I'd also suggest to send out an email reminder to everyone about the issues
they have submitted. That's a) more convenient if there's a plain list to go
through (without having to create that manually by a filter first) and b) you
will also reach those who might not frequent these forums (any more) regularly.

If you're going to do that, also include the SCRs people have put votes on.

Sascha

0

Very good idea. Thanks for coming up with this.
I'll take a look at my request at the end of this week.

0

Please sign in to leave a comment.