Bugday's Integration

Added by Daniel Felix over 1 year ago

Hi community,

we're currently on the way to clean the bugtracker. Currently Redmine has more than 3800 open issues, which is fairly to much for 13 contributors - where not every on is active on a regular base.
If we divide thos issues by maybe 7 active contributors, we have more than 540 issues per person. This is quite too much stuff to handle!

My idea would be some kind of bugday's.

What's the idea behind bugday's?

Bugday's will be one or two days in each month, where the community comes together to beat down the open issues. These bugday's help the core developers to reduce the administrative work and gain the necessary feedback for integrated new features or resolved bugs.

How will the Bugday planned and organized?

This event will be planned with some fixed start- and endtime. During this time, there's minimum one contributor online, which will coordinate and moderate this event.
The community will get some chat channel (maybe IRC) to communicate with the team and start crawling the bugtracker by different criterias.
Criterias could be:
  • Issues with status "Needs Feedback" or "Resolved"
  • Old issues, which haven't any feedback.
  • Issues which have some kind of patch attached
  • Issues which have unsupported versions as affected version
  • Feature requests by categorie
  • Special searchterms

If some user needs help to test a bug or feature, he could request this in the chat channel. The community will help him with his tests or patches.

After this event, we provide some kind of report, which contains resolved tickets, confirmed or invalidated issues. The team will test and evaluate provided patches and try to integrate them as fast as possible.

The team will need minimum one or two weeks for the cleanup and integration.

Why should I contribute?

If you don't know, why you should contribute to these days and spent one or two hours in a week, we'll provide you some good reasons:
  • Redmine is a OpenSource system, which lives from donations and community support. Everyone who is using Redmine benefits from new features or corrected bugs.
  • The most systems, which could be compared to Redmine, costs many thousands of euros. Redmine is provided free of charge.
  • You save many hours a week/month by using Redmine in your company. With more features or lesser bugs, you'll save even more time and money!

How can I contribute?

You can provide your help with different tasks.
  • Test and evaluate bugs
  • Check feature requests if they are unique, if not provide the corresponding issue id
  • Check feature requests if they are already integrated/solved or could be resolved by some configuration changes
  • Provide patches for bugs/feature requests
  • Check provided patches on the currently supported releases
  • Check the current supported releases for bugs
  • Discuss on feature requests, which are marked as hot topics in the bugday event
  • Or even, donate for some features/bugs

Please give some Feedback on this topic, I would be very happy if we could introduce these days.

Best regards,
Daniel Felix

Replies (61)

RE: Bugday's Integration - Added by Jan Niggemann (redmine.org team member) about 1 year ago

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

RE: Bugday's Integration - Added by Jérôme BATAILLE about 1 year ago

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

RE: Bugday's Integration - Added by Mischa The Evil about 1 year ago

Daniel, Jan, welcome to the team ;)

Some references to past efforts of this kind:

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.

RE: Bugday's Integration - Added by Daniel Felix about 1 year ago

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:

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

RE: Bugday's Integration - Added by Daniel Felix about 1 year ago

@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

RE: Bugday's Integration - Added by Dipan Mehta about 1 year ago

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.

RE: Bugday's Integration - Added by Daniel Felix about 1 year ago

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.

RE: Bugday's Integration - Added by Daniel Felix about 1 year ago

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

RE: Bugday's Integration - Added by Ivan Cenov about 1 year ago

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

RE: Bugday's Integration - Added by Ivan Cenov about 1 year ago

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

RE: Bugday's Integration - Added by Ivan Cenov about 1 year ago

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

RE: Bugday's Integration - Added by Dipan Mehta about 1 year ago

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.

RE: Bugday's Integration - Added by Mischa The Evil about 1 year ago

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.

RE: Bugday's Integration - Added by Daniel Felix about 1 year ago

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.

RE: Bugday's Integration - Added by Ivan Cenov about 1 year ago

#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.

RE: Bugday's Integration - Added by Ivan Cenov about 1 year ago

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

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

RE: Bugday's Integration - Added by Ivan Cenov about 1 year ago

#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?

RE: Bugday's Integration - Added by Ivan Cenov about 1 year ago

#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.

RE: Bugday's Integration - Added by Ivan Cenov about 1 year ago

#1192: IE 6.0 Timeout Problem

Who uses IE 6.0 nowadays?

This issue could be closed.

RE: Bugday's Integration - Added by Ivan Cenov about 1 year ago

#1231: project-name to short

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

I think this issue could be closed.

RE: Bugday's Integration - Added by Ivan Cenov about 1 year ago

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

This is already implemented and #1221 can be closed.

Implemented permissions are:
  • Manage forums
  • Post messages
  • Edit messages
  • Edit own messages
  • Delete messages
  • Delete own messages

RE: Bugday's Integration - Added by Ivan Cenov about 1 year ago

#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.

RE: Bugday's Integration - Added by Daniel Felix about 1 year ago

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.

RE: Bugday's Integration - Added by Daniel Felix about 1 year ago

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.

RE: Bugday's Integration - Added by Ivan Cenov about 1 year ago

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.

1 2 3 (1-25/61)