Redmine

Can anyone give an example of some of the most common errors plugin developers run into? Thanks in advance for the help. <spamlink removed by Jan Niggemann>

Eric Davis wrote:

I've just started a page on some of the ways to contribute back to Redmine.

The mentioned forum thread doesnt seem to exist anymore.

I've just tried to submit several patch tickets for lots of our enhancements and bugfixes, but redmine rejects it, tells I'm banned ;-o

Felix Schäfer wrote:

Terence Mill wrote:

Sry, link shall be /projects/redmine/wiki/DeGuide

Last time I looked everyone should be able to start a new Wiki page, so you should be able to start DeGuide yourself. Once you have, it can be linked to from the global Guide page.

I've just created the page DeGuide. Please link to it from the global Guide page.

Is it possible to contribute to the original english guide? I've noticed that it isn't up to date either.

Tobias Spribille wrote:

Felix Schäfer wrote:

Terence Mill wrote:

Sry, link shall be /projects/redmine/wiki/DeGuide

Last time I looked everyone should be able to start a new Wiki page, so you should be able to start DeGuide yourself. Once you have, it can be linked to from the global Guide page.

I've just created the page DeGuide. Please link to it from the global Guide page.

Done, thanks.

Is it possible to contribute to the original english guide? I've noticed that it isn't up to date either.

Which wiki?
I don't know redmine.org wiki permission policy.

Tobias Spribille wrote:
Is it possible to contribute to the original english guide? I've noticed that it isn't up to date either.

I un-locked the Guide and will watch it for abusive changes and wiki-vandalism. If necessary, I'll re-lock it.

Hello,

I installed Redmine some time ago to use it in my Architecture practice (Design Studio) as a collaboration tool. Love it, much better and more powerful than a lot of alternatives out there.

We would like to contribute, first to some localization/translation bugs that caught our eye and some css improvements (clarity, readability and a little bit of informed design here and there). Nothing major, it's a very well thought out app.

How do we get started?

Mir Basil wrote:

We would like to contribute, first to some localization/translation bugs that caught our eye and some css improvements (clarity, readability and a little bit of informed design here and there). Nothing major, it's a very well thought out app.
How do we get started?

Well, the first post in this thread is exactly what you're looking for.
If you have an idea, write a new issue ticket of type "Feature".
If you experienced a problem or annoyance, open a new ticket of type "Defect".

• read Contribute, create a patch and attach it to a issue of the type "Patch" with the category "Translations", or
• just write your enhancements in clear text in an issue ticket.

Hi Jan,

it's sad, that this seems to be the only option to contribute to redmine.
I've opened some defect and feature tickets over the past year, and nothing happend so far.
It seems as the core team is just too small to handle the amount of issues or forum posts – a vicious cycle.
There's so many good feature requests and patches from the community in your trackers which seem to never come to the attention of the redmine core team – for years! Sad story... :-/

As far as I've read through the forums and wiki pages, the core dev team isn't very fond of github pull requests, but I think it could be a great possibility to implement long-awaited features or patches from the community.

Tobias Fischer wrote:

it's sad, that this seems to be the only option to contribute to redmine.

I'm sorry to hear that you're unhappy. What are your expectations, what can we do about it?

I've opened some defect and feature tickets over the past year, and nothing happend so far.
It seems as the core team is just too small to handle the amount of issues or forum posts – a vicious cycle.

Indeed, the core team is small and there's a huge amount of stuff on the trackers - but I wouldn't call it a vicious cycle. Other projects have lost members because they are scared off by the work - it seems too daunting if they look at the sheer amount of tickets. Instead they say 'We'll never make it' and fold. Redmine, to the contrary, is still alive and kicking. "Continuous improvement is better than postponed perfection" is what probably characterizes our development best :-)

There's so many good feature requests and patches from the community in your trackers which seem to never come to the attention of the redmine core team – for years! Sad story... :-/

I wouldn't say so: The core team sifts through the tickets and implements what seems to be a good idea for redmine in general.
There are lots and lots of tickets that propose changes that would just be of value for a very small group of our users. Being too few, we don't waste time thinking about possible implementations. Instead, we regularly advise people to put such functionality into plugins, but these plugins never materialize. I think that the root cause is that those people don't have enough RoR programmers at hand either.
Compare this to the development of the Linux kernel: Linus doesn't integrate patch XY just because someone on the LKML thinks its useful.

As far as I've read through the forums and wiki pages, the core dev team isn't very fond of github pull requests, but I think it could be a great possibility to implement long-awaited features or patches from the community.

We use SVN, but that shouldn't be a problem. Above all, the core team isn't fond of patches that

• are not explained well enough and it's unclear as to what people hint at
• are not accompanied by proper tests
• do not advance redmine into the direction they seem fit

Patches that match these criteria are not likely to be accepted into redmine, while patches that are well explained and accompanied by proper tests are much more likely to get commited.

Perhaps we need to rethink how to accept patches, github is a very popular ressource and lots of people know git quite well.

If you are skilled in RoR and would like to participate in the development of redmine, then please read Contribute. Perhaps you can review the patch queue and check if the patches still apply cleanly (especially the older ones) and if they have good test coverage.

Jan Niggemann (redmine.org team member) wrote:

There are lots and lots of tickets that propose changes that would just be of value for a very small group of our users.

How do you recognize what is most requested and what not? For this I would suggest that you add a voting mechanism to redmine.org tickets. By module or native implementation. I'd love to see which issue or improvement requests are the hotest. And I think it would be also interesting for the core staff as well. Or not? If I'm not wrong, currently, you can only see this by '+1 comments' or you just get the impression this and that is very demanded.

I know, the forum is also a source for getting an impression. But in my opinion there should be some voting mechanism. Maybe also for the forum but for the tickets it is usefuller, I think.

I think this could also be interesting for module developers.

Jan Niggemann (redmine.org team member) wrote:

Indeed, the core team is small and there's a huge amount of stuff on the trackers - but I wouldn't call it a vicious cycle. Other projects have lost members because they are scared off by the work - it seems too daunting if they look at the sheer amount of tickets. Instead they say 'We'll never make it' and fold. Redmine, to the contrary, is still alive and kicking. "Continuous improvement is better than postponed perfection" is what probably characterizes our development best :-)

well, that's a good thing, for sure! and I'm very happe that there's constant development for redmine! Overall, you're doing great work! :) But...

I wouldn't say so: The core team sifts through the tickets and implements what seems to be a good idea for redmine in general.
There are lots and lots of tickets that propose changes that would just be of value for a very small group of our users. Being too few, we don't waste time thinking about possible implementations. Instead, we regularly advise people to put such functionality into plugins, but these plugins never materialize. I think that the root cause is that those people don't have enough RoR programmers at hand either.
Compare this to the development of the Linux kernel: Linus doesn't integrate patch XY just because someone on the LKML thinks its useful.

But for normal users or issue reporters it seems very randomly for what reasons you mark tickets for the next release cycle. And – even worse – you mostly don't get any reaction from the team if they read but postponed the ticket (for reasons)...
sometimes, though, team members leave replies for what reasons a ticket is postponed/not doable in the redmine core and should better be a plugin.
That's okay, for sure – but still, it's about all the tickets which the team might have reviewed once, but didn't comment on, and no one knows about it...

As Robert said, there should be some voting mechanisms to make visible what are important tickets to the users!

We use SVN, but that shouldn't be a problem. Above all, the core team isn't fond of patches that

• are not explained well enough and it's unclear as to what people hint at
• are not accompanied by proper tests
• do not advance redmine into the direction they seem fit

Patches that match these criteria are not likely to be accepted into redmine, while patches that are well explained and accompanied by proper tests are much more likely to get commited.

Yes, but WHERE to place these patches? If I open an issue and append the patch, how likely is it, that you will accept the patch within the next few bugfix releases? For what I experienced here so far, it's very unlikely.
Patches are hanging around for years, getting re-patched again and again, and it seems as no one cares...
And to be honest, seeing and experiencing that, I'm not feeling like providing patches at all. Sorry...

Perhaps we need to rethink how to accept patches, github is a very popular ressource and lots of people know git quite well.

That would be great!

If you are skilled in RoR and would like to participate in the development of redmine, then please read Contribute. Perhaps you can review the patch queue and check if the patches still apply cleanly (especially the older ones) and if they have good test coverage.

But WHERE/WHAT IS the patch queue?! Is it the tickets in milestone "candidate for next minor/major release"? But how do they get there? And what if I want to patch a ticket which isn't in this queue - how can I do without having the impression that my review/patch is lying around dead for months or years?

I really think, git pull-requests could improve this workflow sooo much!

Tobias Fischer wrote:

But for normal users or issue reporters it seems very randomly for what reasons you mark tickets for the next release cycle.

That's true. I also never relate which ticket is why added to the next version. Sure, because it seems important to the project leaders. But why is it important?
I really don't want to complain. I'm happy that Redmine exists (thank you!). But I would be even more happier if I (and other users) could influence the project a little bit when such decisions are made. With the voting suggestion you, the developers, could see what is mostly requested. And if you would realize what is mostly requested you get more users and a better feedback by happy users. And all could see and relate why you have decided to realize a feature instead of fixing a bug, for example.

Tobias Fischer wrote:

I really think, git pull-requests could improve this workflow sooo much!

I'm not very familiar with Git and I don't like hypes. But to me it seems Git and github have changed general development, especially open source development. I think Git is not overestimated and at the end you could also benefit from it.

At least I wish you that you benefit from some technology and that you get the feeling to use it was the right decision!

Perhaps we need to rethink how to accept patches...

Yes, it would be good if the core developers could document their process: how often they will check for patches, how they will give feedback if they reject a patch: whether they have a 'pending list' of patches they have said will be put through, once the work is done to the patch tht has been asked.

And also, a comment whether actually, like many coders, the core developers do not enjoy reading code frm others! Code review is hard work!

If that is a factor, maybe discussions can look at finding help in the community: or building some tools to make that work less time-consuming?

Jan, after our discussion here in the forums, have there been internal discussions in the past month about how contributors/contributions can be better handled by the dev team?
Or probably even about using git? ;-)

Has there been any discussion about the patch queue and some standardized review process?

Tobias Fischer wrote:

Patches that match these criteria are not likely to be accepted into redmine, while patches that are well explained and accompanied by proper tests are much more likely to get commited.

Yes, but WHERE to place these patches? If I open an issue and append the patch, how likely is it, that you will accept the patch within the next few bugfix releases? For what I experienced here so far, it's very unlikely.
Patches are hanging around for years, getting re-patched again and again, and it seems as no one cares...
And to be honest, seeing and experiencing that, I'm not feeling like providing patches at all. Sorry...

Perhaps we need to rethink how to accept patches, github is a very popular ressource and lots of people know git quite well.

That would be great!

If you are skilled in RoR and would like to participate in the development of redmine, then please read Contribute. Perhaps you can review the patch queue and check if the patches still apply cleanly (especially the older ones) and if they have good test coverage.

But WHERE/WHAT IS the patch queue?! Is it the tickets in milestone "candidate for next minor/major release"? But how do they get there? And what if I want to patch a ticket which isn't in this queue - how can I do without having the impression that my review/patch is lying around dead for months or years?

Providing patches is fun for a (voluntarily) contributor if patches are beeing applied to the software somewhen in the near future.
But it gets annoying for likely contributors if patches are hangin' around for years and need to be re-patched again and again...

I'm fairly new to Redmine and am using it extensively in a customized deployment at work. Looking through many of the issues, I've had the same concern tempering my desire to contribute - lots of issues with patches that have received no response up or down for years. The Contribute page points to updating these patches to work with the current master as a priority, but this effort seems pointless without knowing whether the updated patch will just sit for another N years and need to be updated again. Case in point: I've just submitted a patch for #4518 and, looking at the history of that thread, you can understand my concern that I've just wasted my time.

I use Git, and moving to GitHub would without a doubt encourage more developer contribution, given that most active Ruby projects live there. But advocating for Git misses the point of this thread. More contribution would only exacerbate the problem of contributions not going anywhere.

My suggestion is for the core team to use either an issue status or (better) future versions to indicate issues that, if properly patched, will be prioritized for inclusion in the next (or next-next) release. This would strongly encourage folks to provide patches for issues that will actually be acted upon. And if an issue comes in that will definitely not be acted upon (e.g. it should really be a plugin), use a status to say so and save the time of well-meaning developers who create a patch for it.

Hi all,

We are using Redmine for most of our clients.
We're usually contributing to open-source projects and it seems weird that Redmine is an exception.

- I'm currently interested in the REST API as my project is to integrate Jenkins CI and Redmine to publish project Releases
- I have no RoR prior experience

I have found feature requests which match my problematic: #18245, #13800, #7725
However it seems unlikely that a developper subscribed as a watcher after the first sorting pass.

So I need pointer to:
- is my feature acceptable ? (REST API for files)
- where (or with who) can I discuss the implementation (since files are actually a category of attachments would it be better to provide a CRUD methods for attachments which would also solve REST API for Documents and REST API for Files/Versions, etc.) ?
- How do you gain contributor permission ?

My outstanding wish would be to integrate it in Redmine 3.0.0 roadmap :)

Hi all,

I want to contribute in Korean translation of Redmine Guide.
I have 1 year user experience and 2-month admin experience in redmine.

Please direct me to contribute Korean translation of Redmine Guide.

Thanks for your efforts on redmine.

BR.

There is no consensus about Guide translation (#8203),
but some translations are on Redmine.org: Guide .

Can one of the core guys give me a more powerful login to the Wiki?

I'd like to take some time tidying up the plugins pages: there are many pages!
Plugins link to Github pages, where sometimes the code is very old - but there are sometimes other forks on Github that work with more recent Redmine versions.

If I had better access, I could update those plugin pages.

Or delete the ones that are no use to the reader: eg this one, which gives no way for the reader to get the plugin other than personal contact to the author
- http://www.redmine.org/plugins/access_tickets

In terms of can you trust me?! I already tidy up the Themes page every so often:
http://www.redmine.org/projects/redmine/wiki/Theme_List

• searching for new themes and adding them
• searching for newer versions of existing themes
• adding helpful links at the top of the page to UI -relevant plugins / CSS things etc

Eric Davis wrote:

I've just started a page on some of the ways to contribute back to Redmine. I'll be improving it over time but I wanted to get a list of some common tasks that I can direct people to. If you're interested in contributing but need help finding something specific to do, post a comment in this thread with the following and I'll try to point you in a general direction.

• what interests you (e.g. plugin development, documentation)
• your experience with Redmine, Ruby on Rails, and anything else (e.g. several years experience, new to it but wanting to learn)

Eric

i need help "step by step" guide to install redmine latest version on my linux server. i am not having any developing or server admin knowledge. please help.

Here you can find a set of *step by step guides how to install Redmine* and its components (plugins, themes), also on Linux server.

i am interested to make a plugin to publish

Jessica Bennett wrote:

i am interested to make a plugin to publish

Sounds great! :-)

Feel free to ask on the forums if you have any questions.

Hi Redmine Team,
I built some plugins for redmine, have some experience with Redmine and based in that I like to contribute to Redmine, building plugins or add features to it. How I can participate in the project?, Thanks a lot.

Hi Anderson Alvarez,

welcome to the Redmine community. We are happy that you would like to contribute to Redmine. :-)

There are several ways to contribute. Many of them are listed on the wiki page Contribute. Don't trust it too much as there isn't any kind of specialized team which is active nowadays. I think crawling through the issue tracker and trying to squash some bugs or adding a small feature is a good start. ;-) Helping out on the forums is also a great way of contribution.

If you would like to talk to the more active developers of Redmine, we have a brand new Slack channel you can join. https://join.slack.com/t/redmineorg/shared_invite/zt-cai4czxe-wzRbARcXk6otbjJgwhS5zw