Top Menu

Jump to content
Home
    • Projects
    • Work packages
    • News
    • Getting started
    • Introduction video
      Welcome to OpenProject Community
      Get a quick overview of project management and team collaboration with OpenProject. You can restart this video from the help menu.

    • Help and support
    • User guides
    • Videos
    • Shortcuts
    • Community forum
    • Professional support

    • Additional resources
    • Data privacy and security policy
    • Digital accessibility (DE)
    • OpenProject website
    • Security alerts / Newsletter
    • OpenProject blog
    • Release notes
    • Report a bug
    • Development roadmap
    • Add and edit translations
    • API documentation
  • Sign in
      Forgot your password?
      Create a new account

      or sign in with your existing account

      Google

Side Menu

  • Overview
  • Activity
  • Roadmap
  • Work packages
  • Calendars
  • Team planners
  • Boards
  • Forums
  • Wiki
    • Table of contents
      • Expanded. Click to collapseCollapsed. Click to showDeveloper
        • Hierarchy leafAccessibility Checklist
        • Hierarchy leafCode Review Guidelines
        • Expanded. Click to collapseCollapsed. Click to showContribution
          • Hierarchy leafGit Workflow
          • Hierarchy leafTranslations
        • Expanded. Click to collapseCollapsed. Click to showDeveloping Plugins
          • Hierarchy leafDeveloping an OmniAuth Authentication Plugin
        • Hierarchy leafRelease Process
        • Hierarchy leafReport a bug
        • Hierarchy leafSecurity
        • Hierarchy leafSetting up an OpenLDAP server for testing
        • Hierarchy leafTheme Features
      • Hierarchy leafDownload
      • Expanded. Click to collapseCollapsed. Click to showFeature tour
        • Hierarchy leafRelease Notes OpenProject 30
        • Expanded. Click to collapseCollapsed. Click to showRelease Notes OpenProject 30 - Overview
          • Hierarchy leafGlossary
          • Hierarchy leafRelease Notes - Accessibility
          • Hierarchy leafRelease Notes - Accessibility changes
          • Hierarchy leafRelease Notes - Add work package queries as menu items to sidebar
          • Hierarchy leafRelease Notes - Copy projects based on Templates
          • Hierarchy leafRelease Notes - Design changes
          • Hierarchy leafRelease Notes - Fixed Bugs
          • Hierarchy leafRelease Notes - Keyboard Shortcuts
          • Hierarchy leafRelease Notes - Project settings
          • Hierarchy leafRelease Notes - Ruby&Rails Update
          • Hierarchy leafRelease Notes - Security
          • Hierarchy leafRelease Notes - Timelines
          • Hierarchy leafRelease Notes - Work packages
      • Hierarchy leafHowto create animated gifs
      • Hierarchy leafMigration Squashing
      • Hierarchy leafMod security
      • Hierarchy leafNew work package page
      • Hierarchy leafOP3 to OP4 Debian upgrade
      • Hierarchy leafOP4 Ubuntu1404 Stable with MySQL in production
      • Hierarchy leafOpenProject 40 Development Setup
      • Expanded. Click to collapseCollapsed. Click to showOpenProject Foundation
        • Hierarchy leafBoards
        • Hierarchy leafMembers
        • Hierarchy leafOPF-Meetings
        • Hierarchy leafStatutes
      • Expanded. Click to collapseCollapsed. Click to showRelease Notes
        • Hierarchy leafOpenProject released on Bitnami
      • Expanded. Click to collapseCollapsed. Click to showRelease Notes OpenProject 40 - Overview
        • Hierarchy leafRelease Notes OpenProject 40 - Accessibility improvements
        • Hierarchy leafRelease Notes OpenProject 40 - Column header functions in work package table
        • Hierarchy leafRelease Notes OpenProject 40 - Improved Design
        • Hierarchy leafRelease Notes OpenProject 40 - Integrated query title on work package page
        • Hierarchy leafRelease Notes OpenProject 40 - Integrated toolbar on work package page
        • Hierarchy leafRelease Notes OpenProject 40 - OmniAuth integration for OpenProject
        • Hierarchy leafRelease Notes OpenProject 40 - Work package details pane
      • Expanded. Click to collapseCollapsed. Click to showSecurity and privacy
        • Hierarchy leafFAQ
      • Expanded. Click to collapseCollapsed. Click to showSupport
        • Expanded. Click to collapseCollapsed. Click to showDownload and Installation
          • Hierarchy leafInstallation MacOS
          • Expanded. Click to collapseCollapsed. Click to showInstallation OpenProject 3 0
            • Hierarchy leafDebian Stable with MySQL in production
            • Hierarchy leafInstallation Ubuntu
            • Hierarchy leafInstallation Windows
            • Hierarchy leafInstallation on Centos 65 x64 with Apache and PostgreSQL 93
          • Expanded. Click to collapseCollapsed. Click to showInstallation OpenProject 40
            • Hierarchy leafOP4 Debian Stable with MySQL in production
          • Expanded. Click to collapseCollapsed. Click to showMigration paths
            • Hierarchy leafFrom Chilliproject to OpenProject
            • Hierarchy leafMigration 15 to 30
            • Hierarchy leafMigration 24 to 30
            • Hierarchy leafMigration Redmine 2x › OpenProject 30
            • Hierarchy leafOpenProject 3 Migration
          • Hierarchy leafOpenProject 40
        • Expanded. Click to collapseCollapsed. Click to showNews
          • Hierarchy leafNew OpenProject Translations Plugin
          • Hierarchy leafNew Plugin on OpenProjectorg Local Avatars
          • Hierarchy leafNew design for OpenProject
          • Hierarchy leafNews Accessibility workshop for OpenProject
          • Hierarchy leafNews Glossary for OpenProject
          • Hierarchy leafNews Heartbleed fixed
          • Hierarchy leafNews Icon Fonts
          • Hierarchy leafNews OpenProject 30 Release
          • Hierarchy leafNews Release GitHub Integration Plugin
          • Hierarchy leafNews Success Story Deutsche Telekom
          • Hierarchy leafNews Timelines
          • Hierarchy leafOpenProject 3013 released
          • Hierarchy leafOpenProject 3017 released
          • Hierarchy leafOpenProject 40 released
          • Hierarchy leafOpenProject 40 will be coming soon
          • Hierarchy leafOpenProject 405 released
          • Hierarchy leafOpenProject and pkgrio
          • Hierarchy leafOpenProject news moved to a new blog
          • Hierarchy leafOpenProjectBitnami
          • Hierarchy leafPackager version with plugins released ("Community edition")
          • Hierarchy leafRegistration OpenProject-Foundation
          • Hierarchy leafRelease OpenProject AuthPlugins
          • Hierarchy leafUpdates on OpenProject
          • Hierarchy leafWe need your feedback for the the new fullscreen view for work packages
        • Hierarchy leafOpenProject Plug-Ins
      • Hierarchy leafWiki
You are here:
  • Forums
  • Development

Content

Contributions

Added by jason southwell almost 9 years ago

We are just now getting underway with Open Project in our daily workflow and already I’m getting tons of requests in to smooth the process or otherwise improve usability.

I’m likely at some point going to have to start modifying OpenProject to suit our needs. Obviously the priorities for my users are not going to always mesh with those of the OpenProject team. As such, it doesn’t make sense for me to necessarily contribute as a member of the team but I’m wondering what the process and policy is for non-scheduled changes to the product. If I make several changes on my end and send them over, are they likely to be considered for inclusion in the product even if it doesn’t mesh with timeline and defined sprints?

And if so, what is the process you’d like me to follow?


Replies (2)

RE: Contributions - Added by Jens Ulferts almost 9 years ago

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

RE: Contributions - Added by Deleted user over 8 years ago

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

  • (1 - 2/2)
Loading...