Redmine

I like this idea!¶

It's going to be a lot of work to organize this, but I'm willing to help where I can to clean the trackers.

Jan

I like this too, have the technical skills to help !

Daniel, Jan, welcome to the team ;)

• wiki pages:
  • Bugmash & BugMash-10
  • Contribute
  • IRC
  • Submissions
• forum threads:
  • Bugtracker triage on sunday 16.05.2010
  • Request: "Clean" out the issues on Redmine.org

Daniel Felix wrote:

Criterias could be:
Issues which have unsupported versions as affected version

I am not sure if that will be a good criterium, since most of such custom field values expresses the Redmine version the initial issue author opened his issue against. An old defect could be affecting e.g. >= 1.2.0 and still be valid, open and/or unfixed.
Besides, it might be that J-PL or other committers are using this custom field value for merging-purposes. I am not sure about that. But if correct, such a criterium, could break committer workflow.

[...]
Special searchterms

I happen(ed) to use the issue list filters actively in the recent past. Specifically the subject and category filters can provide quick results of matching related issues.

Hi Mischa,

Mischa The Evil wrote:

Daniel, Jan, welcome to the team ;)

Thanks! :-)

Mischa The Evil wrote:

Some references to past efforts of this kind:

• wiki pages:
  • Bugmash & BugMash-10
  • Contribute
  • IRC
  • Submissions
• forum threads:
  • Bugtracker triage on sunday 16.05.2010
  • Request: "Clean" out the issues on Redmine.org

Yes I've already seen this threads and pages. But they seem to be more than a one-time event as a regular event. I'm pretty sure, that you're the same opinion, that the current tracker is fairly to big to handle by those few persons. ;-)
The point is, just in case that those events were planed a few times and won't get it to a regular event - this won't be a reason to try it again. ;-)

Mischa The Evil wrote:

Daniel Felix wrote:

Criterias could be:
Issues which have unsupported versions as affected version

I am not sure if that will be a good criterium, since most of such custom field values expresses the Redmine version the initial issue author opened his issue against. An old defect could be affecting e.g. >= 1.2.0 and still be valid, open and/or unfixed.
Besides, it might be that J-PL or other committers are using this custom field value for merging-purposes. I am not sure about that. But if correct, such a criterium, could break committer workflow.

Yes you'r right, but those versions should be still reviewed. Even if the developers use those categories for commitworkflow or something else. If a feature request is solved in the current releases or a bug is solved, there is no legit reason why this issue should stay open in the current trunk, doesn't it?

Mischa The Evil wrote:

[...]
Special searchterms

I happen(ed) to use the issue list filters actively in the recent past. Specifically the subject and category filters can provide quick results of matching related issues.

Same as me. I just take the workflow category and checked the issues. Nearly 50% are duplicates or solved by #8050 or could be solved after integration of #12005. I'm pretty sure that many of those tickets could be rechecked.
Another thing would be categorization. Many tickets won't have any category. Those could be categorized and grouped. Which is also a good thing, just in case for analyzing new requests.

Best regards,
Daniel

@Community
Maybe you can help us identifying bugs.

This could be easily be done, by filtering the current issue list by "status = Needs Feedback".

Please give some feedback on this issues, if you're able to reproduce this issues.
Just give some comments on this, we'll check this issues regularly.

Testing this issues will help us to keep the tracker down and improve our development.

Thanks in advance,
Daniel

Hi people,

I am quite new to being a member of this site, but I have been looking at Redmine for sometime now.

Will be happy to help.

Unfortunately, I don't quite use IRC. Is it ok, if I directly add notes to Issues?

Dipan.

Yes this would ne okay too. Maybe you can recheck issues with "Needs Feedback" or check some oder issues which are pretty old. Maybe you can give some hints for issue relations or check new issues if they already exists in some older request.

All off the above would be a great help for the team.

Thanks in advance.

By the way. We are on the way to break the 3900 border of open issues.

#811: Username validation - allow spaces... There is a patch given in the issue. If this patch is safe it could be implemented.

#867: Want more wiki link types -- I have impression that this is already implemented, so #867 could be closed.

#709: Show attached images on issue body -- Attached images may be shown in issue body. This issue could be closed...

I think if we want to get open issue count drastically - we should start out issues which are easiest to integrate but are lying for a long time just because not enough attention got into it (relative to others).

In this regard: few things can be done immediately -

1. Attacks bugs and see first of all if they are reproducible
a. if yes - mark them critical / good to go
b. if no - mark them non-reproducible (author should help reproduce unless we shall close it)
From me: I will try to perform best possible testing for above (in environment I use)

2. Let's declare the release that is no longer supported and we shall close issues which are pertaining to it.

3. Attack all the patches (including features for which patches are attached) - and test to validate two aspects
a. whether it correctly implements the said functionality
b. it doesn't break or hard code anything.
if it is ok in both ways, we should mark them ready to integrate.
Again - I can help you do some of these testing and put my opinion on it.

If this sounds good, I will update the relative issues and make up the list here.

Dipan.

Ivan Cenov wrote:

#867: Want more wiki link types -- I have impression that this is already implemented, so #867 could be closed.
#709: Show attached images on issue body -- Attached images may be shown in issue body. This issue could be closed...

Thanks for mentioning these. I've closed them accordingly.

Dipan Mehta wrote:

I think if we want to get open issue count drastically - we should start out issues which are easiest to integrate but are lying for a long time just because not enough attention got into it (relative to others).

Well but many of these obviously small thinks have a bigger impact on the code.
It would be better to evaluate these bugs if they are still present on the currently supported versions. Maybe this rare already resolved. If not, add a short note on this issue "still confirmed on Redmine v...."

Dipan Mehta wrote:

1. Attacks bugs and see first of all if they are reproducible
a. if yes - mark them critical / good to go
b. if no - mark them non-reproducible (author should help reproduce unless we shall close it)
From me: I will try to perform best possible testing for above (in environment I use)

This could be done by adding some note on the issue - like mentioned above.
The marking as critical would be bad!

For example: There is a bug that the CSS color for links weren't applied on links. And the login could be hacked.
Both are confirmed and will be critical?! No!
Just set them to confirm or let us set them to confirmed.

Another idea would be to recheck issues which are set to confirmed. It would be good to evaluate this.
Some bugs were corrected by including another bug fix.

Dipan Mehta wrote:

2. Let's declare the release that is no longer supported and we shall close issues which are pertaining to it.

Well normally just the currently available downloads will be supported. But maybe there could be some longtime supported version.
But there older bugs still need to be evaluated.

Dipan Mehta wrote:

3. Attack all the patches (including features for which patches are attached) - and test to validate two aspects
a. whether it correctly implements the said functionality
b. it doesn't break or hard code anything.
if it is ok in both ways, we should mark them ready to integrate.
Again - I can help you do some of these testing and put my opinion on it.

Yes I would totally agree. But many of them doesn't provide a test. Which is necessary for new implementation.
And many patches were very hacky or doesn't apply cleanly on the trunk.

The main think is: get more attention to the tracker and give more feedback on bugs and requests.

#1069: "Help" link should launch new page.
IMHO, this should not be implemented, because while some people want this, other people do not want it.
So, let default behavior remain as is.

#1030: Adding comments is not an "activity"?

Adding comments (notes) to issues is is reported in Activity; #1030 could be closed.

#1022: Patch for #1003: Allow "New Issue" from anywhere

This is outdated, I tried with current trunk and it did not work.

May be #1022 and #1003 should be closed?

#1265: Add ability to delete Versions

Deleting versions is implemented. Redmine asks "Are you sure?" and then tries deleting. However deleting does not proceed if versions have issues assigned.

I think this issue could be closed.

#1192: IE 6.0 Timeout Problem

Who uses IE 6.0 nowadays?

This issue could be closed.

#1231: project-name to short

Nowadays, projects can have names at least 80 characters long.

I think this issue could be closed.

#1221: user should have permissions which can edit/delete the messages posted by himself

This is already implemented and #1221 can be closed.

• Manage forums
• Post messages
• Edit messages
• Edit own messages
• Delete messages
• Delete own messages

#1294: Gantt Chart: Show/Hide Right Menu

The plugin https://github.com/ries-tech/sidebar_hide does this job.

I think this issue could be closed.

Ivan Cenov wrote:

#1069: "Help" link should launch new page.
IMHO, this should not be implemented, because while some people want this, other people do not want it.
So, let default behavior remain as is.

Well this is related to some other issue. There is another request which means disabling the help link.
I think the new window/tab should be implemented or minimum indicated as external link (as described in the issue - I think).
Opening the link in the same tab leads to many issues on Redmine which should go to the internal support. We currently delete all of this wrong issues.

Well on the other issues I would agree.

But those hide sidebar more likely seems to be a little implementation which is it worth to implement in the core. Which would resolve some other issues and give a better overview.
I have another implementation on my PC. But I'm currently not at home and can't upload a patch.
But some building hide sidebar would be a nice thing. Maybe the patch could find its ways in 2.4.

Daniel Felix wrote:

Ivan Cenov wrote:

#1069: "Help" link should launch new page.
IMHO, this should not be implemented, because while some people want this, other people do not want it.
So, let default behavior remain as is.

Well this is related to some other issue. There is another request which means disabling the help link.
I think the new window/tab should be implemented or minimum indicated as external link (as described in the issue - I think).
Opening the link in the same tab leads to many issues on Redmine which should go to the internal support. We currently delete all of this wrong issues.

I replaced this in our instance to point to an internal link (wiki help page) and have forgotten that the link points out to Redmine site. I agree now that this link should open in new tab or window.