Hi Jason,

first of all, yes, we will consider every contribution and welcome you to work on OpenProject. As OpenProject is a rather large project, we are in fact looking for people who are interested in improving it. I thought my kind of pushy answers to your bug report made that clear.

When looking at the wiki page about contributions I can understand that it leaves a couple of questions unanswered. But it should get you started.

The basic flow should be along this line:

1) A package clarifying your intend would be great before you even start actively working on anything. It should briefly describe the requirements and the technical approach you are taking towards fulfilling them. For bugs, this will of course be easier. If on the other hand you e.g. want to introduce additional dependencies we should definitely agree upon that upfront.
Writing a package upfront, we can avoid work being done for something that will absolutely not align with the goal of OpenProject or it's architecture. If that is the case, a plugin might be more fitting. In my experience, it is easier to maintain a plugin than to maintain your own fork of OpenProject. For example, we have a plugin that is very specific to privacy requirements of a certain company. Forcing this onto OpenProject itself would make using OpenProject less pleasurable for all of us. On the other hand, some features started as plugins and where later added to OpenProject itself. I am pointing out plugins this explicitly as there probably will be a case where the changes you propose might not align with what OpenProject is about. But we will definitely try to figure out a solution that will work for all of us.

2) Once you start working on it please signal so (“In progress”) in the package you created to avoid multiple people working on it. You might want to open a PR on GitHub early even if it is not yet finished. That way we become aware of what you are doing and get a chance to look over it early on. It would be easier for us to know that you are still working on it when you mark the PR with something like “[WIP|” in the title. As you are working on it for yourself you can of course work independently from our schedule. In case of questions coming up, we are of course willing to help you out.

3) Again, when you are finished, use the package to let the world know ("Developed").

4) We will then take a look at it as soon as possible. This might take some time however as it is done on a best effort basis. We are working in sprints and depending on the size of the PR we can simply squeeze it in or will have to schedule the review in our sprint planning.

5) After review and QA, your contribution will be merged into dev (signaled by "Reviewed", "Tested", "Closed").

6) Depending on the nature of the PR (bugfix vs. feature) your contribution will become part of a stable release sooner or later. We are currently planning to release a major/minor version every 3 month. Bugfixes may be ported to the current release faster, but we haven’t decided on a schedule for that, yet.

I hope this gives you an idea of how contribution works. Let me know if you need more information.

Best

Jens

Hi Jens,

I tried to follow your suggested process. But after I created the work package for my proposed feature (#12623) I could no longer update the fields for neither Status nor Assignee. So I have no way of setting my self as the assigned developer and cannot I set the work package status as neither In progress nor Developed.

Anyhow I tried to update the work package as well as possible by filling out the Notes field instead.

Best regards
Björn