Redmine

I am interested in plugin development but I have no Rails experience so far. However, I don't mind starting out with documentation if it helps understanding the code base better. I have been trying to learn Ruby and looking for a hands on experience on a real project, hence Redmine looks interesting.

Himanshu Chhetri wrote:

I am interested in plugin development but I have no Rails experience so far. However, I don't mind starting out with documentation if it helps understanding the code base better. I have been trying to learn Ruby and looking for a hands on experience on a real project, hence Redmine looks interesting.

I didn't have any Rails experience, but was able to throw together the Schedules plugin in relatively little time. I don't know about others, but I found diving into the code and trying to accomplish some tasks helped a fair bit.

I'd like to make some code contribution, I have little Ruby/Rails experience and wanting to learn more.

I've implemented Redmine in the company I work, for developers and for managing internal projects and work.

I have an idea for directing people like me to the right code, maybe something like the [[http://janitor.kernelnewbies.org/|Linue KernelJanitor Prokect]], that gets a list of simple tasks that are a little boring for some people.

Things like :

• little design typos
• make code apply some standard
• simple refactor (var rename, indenting ...)

If some experienced redmine developer could list things like that in a wiki page, and will increase collaboration, and keep boring tasks for the newbies to dive into the code, and get familiarized.

... fixing link typo

Linux Kernel Janitor Project - http://janitor.kernelnewbies.org/

Enderson Maia wrote:

I have an idea for directing people like me to the right code, maybe something like the [[http://janitor.kernelnewbies.org/|Linue KernelJanitor Prokect]], that gets a list of simple tasks that are a little boring for some people.

That's the number one reason I've been thinking about adding tagging to Redmine. I'd love to tag an issue as "bite-sized" so new people can pick up a part that isn't too difficult but will get them into the process.

If some experienced redmine developer could list things like that in a wiki page, and will increase collaboration, and keep boring tasks for the newbies to dive into the code, and get familiarized.

That's a good idea but it would take some work to maintain the page and keep in sync. Redmine (Rails) has rake task that will print out all the comments flagged with TODO/FIXME/OPTIMIZE. I could tag parts of the code with something like that as I work and let others come in and pick it up. What do you think?

Eric

Eric Davis wrote:

That's the number one reason I've been thinking about adding tagging to Redmine. I'd love to tag an issue as "bite-sized" so new people can pick up a part that isn't too difficult but will get them into the process.

Custom issue field: difficulty? :P

Eric Davis wrote:

Enderson Maia wrote:

If some experienced redmine developer could list things like that in a wiki page, and will increase collaboration, and keep boring tasks for the newbies to dive into the code, and get familiarized.

That's a good idea but it would take some work to maintain the page and keep in sync. Redmine (Rails) has rake task that will print out all the comments flagged with TODO/FIXME/OPTIMIZE. I could tag parts of the code with something like that as I work and let others come in and pick it up. What do you think?

Maybe it wold be better if for each TODO note, you cold relate/create a ticket, if you let a newbie make contributions based on the rake notes, it could lead to duplication off efforts. Duplication occurs with a ticketing system, imagine without it.

If the wiki is a problem to keep in sync, maybe more custom reports and a better triage cold help.

The Contribute is a start, I think another step is create more custom reports in the tickets area and tell every one that wants to help updating the Contribute page.

I think that you cold create a wiki with a list of developers (macro?) and what they are responsible for, in a per ticket category base, so it wold make easy for people that want to help with ticket triage.

The discussion is about how to make contribution easier, more than it already is.

Am I getting out of the topic ?

Enderson Maia wrote:

Maybe it wold be better if for each TODO note, you cold relate/create a ticket, if you let a newbie make contributions based on the rake notes, it could lead to duplication off efforts. Duplication occurs with a ticketing system, imagine without it.

Good point.

If the wiki is a problem to keep in sync, maybe more custom reports and a better triage cold help.

I'd love some better issue triage. That alone would be a huge contribution.

The Contribute is a start, I think another step is create more custom reports in the tickets area and tell every one that wants to help updating the Contribute page.

Another good idea. We'll probably have to start adding some more categories for the filters to get.

I think that you cold create a wiki with a list of developers (macro?) and what they are responsible for, in a per ticket category base, so it wold make easy for people that want to help with ticket triage.

Something like?

• Eric - plugins
• Jean-Philippe Lang - everything that isn't a plugin :)

Am I getting out of the topic ?

Not at all, this is the exact conversation I want to have. I don't mind spending some time if it will help others contribute.

Eric

Eric Davis wrote:

Enderson Maia wrote:

I think that you cold create a wiki with a list of developers (macro?) and what they are responsible for, in a per ticket category base, so it wold make easy for people that want to help with ticket triage.

Something like?

• Eric - plugins
• Jean-Philippe Lang - everything that isn't a plugin :)

Yeah! That's it.

Another idea is to have something in the workflow to automatically assign a ticket to someone based on the category, but that's more a feature request for redmine itself.

I use a system called GLPI for inventory and service desk, and it has a function to make thing like this:

• If the $user is from group 'Presidence' then change ticket priority fro HIGH
• If ticket_title contains 'windows*vista' then set assigned_to to 'bill gates' and category to 'SO'

This helps a lot on the triage.

Based on a recnet ticket (#2866) I reported , I thought on document that could be created to help new contributors.

A wiki page with some rules about the i18n var names, and a little task to get all messages that are not using the l(:var) code, and maybe adapt the actal i18n var names to the rules.

Enderson Maia wrote:

Another idea is to have something in the workflow to automatically assign a ticket to someone based on the category, but that's more a feature request for redmine itself.

Redmine can already auto-assign new issues to a specific user based on the category. I just took the Plugin category since I work with them the most.

Eric

I wanna help more, but I'm a little lost. I'm more familiarized with git and forking, I can deal with patches, but I need more information to collaborate on the right issues.

About the issues, what are the priorities ?

I'd like to help in the bugs triage, but I need permission and I need more info about whats going in each future releases, so I can do a triage for versions.

versions 0.8.3 says nothing on the Roadmap page, and 0.9 has little information, what about future releases, 1.0, 2.0 ...

Enderson Maia wrote:

I wanna help more, but I'm a little lost. I'm more familiarized with git and forking, I can deal with patches, but I need more information to collaborate on the right issues.

About the issues, what are the priorities ?

Depending on how much you know about Redmine, it might be easier to not worry about the issues yet. Here's one process that I'm advising a few other people to follow:

1. Play with Redmine for a bit to understand the UI and where things are located.
2. Read through the data model to understand how the data relates. (app/models)
3. Next, you should pick one area that is interesting to you. For me, I picked the Time Entries and time logging area. If you don't have a specific interest, pick one randomly.
4. Now try to understand how the controllers work with the data and the views for that area. You don't need to be an expert, just familiar with the different methods and helpers used.
5. Now run the rcov report (rake test:coverage) and see if there is any parts of the code that isn't tested (it will be red). The most common places that are lacking tests are the else branches of if statements and other non-default paths.
6. Write a test that will exercise that area. All your are looking for is to make the coverage report for that section turn green and the behavior to be what the code says.
7. Once you have a test, open a new issue for it and attach the patch
8. Then people will review the patch and apply it once it's ready. You might get some feedback on it and need to make some improvements.

After you do this a couple of times you'll start to get into the flow of it and will be able to spot issues that you can handle. Work on these the same way as you did the test patch.

If you need any help, I (and others) can help guide you. The same basic process can be done for documentation, just change step 5 to running rake doc:app and try to fill in the method documentation.

Eric

Eric

Good, I'll try to follow that, this could be a wiki.

I think that could be created a series of wikis on how to collaborate, like the Guide* something like DevGuide*, and the Eric's previous post is a start.

Eric Hulser: This list is excellent! I was looking for some ideas/ways how to start first.
I agree that this should be a Wiki entry, for sure something that several people could be interested in.

Eric, our company wants to migrate to Redmine. I watch for the project already one year and very like it.

But I concern about community of the project. There is only Jean, who commits something in trunk of Redmine. What if Jean will suddenly stop working on the project? Who has access to Redmine's SVN repository? Will the project live forever? =)

In case, if our company will migrate to Redmine, I'm sure - we will contribute many things (we are software development company that likes to contribute something to open-source ;) ). But I want to know, how the contributing is structured - community is very important for open-source projects like Redmine, I think.

Hm... Sorry, I've went through all contributors activities and found that they have access to repository. No questions more =) Thanks for your great work! Redmine is best! =)

Anton Nepomnyaschih wrote:

...I've went through all contributors activities and found that they have access to repository. No questions more =)...

Not completely true. Not all users with the "Contributor"-role here on redmine.org have write-permissions to the Redmine SVN repo.
You can see a list of (RubyForge) users who do have write-access to the repo here: http://rubyforge.org/project/memberlist.php?group_id=1850.

HTH and kind regards,

Mischa.

Anton Nepomnyaschih wrote:

But I concern about community of the project. There is only Jean, who commits something in trunk of Redmine. What if Jean will suddenly stop working on the project? Who has access to Redmine's SVN repository? Will the project live forever? =)

I also have commit rights to the svn repository but I'm not as active in the core as Jean-Philippe. I also maintain the git mirror on GitHub so the repository will always be available.

In case, if our company will migrate to Redmine, I'm sure - we will contribute many things (we are software development company that likes to contribute something to open-source ;) ). But I want to know, how the contributing is structured - community is very important for open-source projects like Redmine, I think.

The Contribute page lists some areas we are looking for help with. Any code contributions should be sent to the issue tracker, either as an attachment to an existing issue or a new "Patch" issue. Right now, we really need some people to help triage the issues list. Like review patches to see if they apply to the latest trunk, if they have tests, etc.

Eric

Eric Davis wrote:

The Contribute page lists some areas we are looking for help with. Any code contributions should be sent to the issue tracker, either as an attachment to an existing issue or a new "Patch" issue. Right now, we really need some people to help triage the issues list. Like review patches to see if they apply to the latest trunk, if they have tests, etc.

Eric, under 'triage' do you mean, that you need someone who can say what features are most important? I have wide experience in project/requirements/risks management and manage team of 20 software developers now. Also, I write dissertation about Project-tracking systems. So, if I could help you with decision what features are most important, I would be very glad.

BTW, could you, please, tell how do you or Jean decide what to implement next? I think, the strategie is very important and fate of the project is dependent on it.

How does one contribute triage? For example, I'm interested in working on issue #2906, which is a near-duplicate of #1179, which has a note stating that #1358 would be solved by the same fix. How would I go about submitting the duplication/relation report?

Michael Burton wrote:

How does one contribute triage?

Mischa's been doing this a lot so he might have some pointers to how he works. I think the best way is to watch the RSS feeds for new issues. When a new issue is posted, see if it's a duplicate or related to an existing issue. Then check that the correct category is set (e.g. Wiki). If you can't edit some parts of the issue, just post a note about what should be changed and one of us will change it for you.

For example, I'm interested in working on issue #2906, which is a near-duplicate of #1179, which has a note stating that #1358 would be solved by the same fix. How would I go about submitting the duplication/relation report?

Looking at those three, they are similar but not the same. So I'd add an issue relation between all three. That would help the developers see the group as a whole and try to fix them all at once. e.g. #2906 is related to #1179, #2906 is related to #1358, #1179 is related to #1358.

Eric Davis

Hi for all. I am a plugin developer for the redmine and I am interested in how i can report development mistakes on redmine core that perhaps happen under development in some plugin.

make whole the post above, a possible mistakes would be erros when server is started.

Thales Ferreira wrote:

Hi for all. I am a plugin developer for the redmine and I am interested in how i can report development mistakes on redmine core that perhaps happen under development in some plugin.

You can report them as bugs but it would be best to start a new forum thread first, especially if you are developing a plugin. Some plugin development errors look like Redmine errors form how Rails works in development mode.

Eric Davis