Skip to content

Latest commit

 

History

History
39 lines (25 loc) · 2.63 KB

README.md

File metadata and controls

39 lines (25 loc) · 2.63 KB
Raw

Equipment Status Viewer

Version 1.0.1

Equipment Status Viewer is a Redmine plugin that tracks the location of equipment. It uses a check in system to track where each item is. It can also print out a QRCode label that your iPhone or Andriod phone can snap and check in quickly. Simply updated it to support redmine 3.2.x and 3.3.x.

Licensed under GPL v3 or earlier.

Contributing

I am not maintaining this. I wrote this a long time ago and have no intention to continue working on it all by myself. What this means is I need you to contribute!

Individuals making significant and valuable contributions are given commit-access to the project to contribute as they see fit. This project is more like an open wiki than a standard guarded open source project.

Trust me on this! I will hit that merge button so fast! Seriously, all you need to do is fork and edit the code. So send me Pull Requests please! On the flip side if I get just an issue asking for some feature or if this can be upgraded to the latest version of Redmine or Rails I will close it with the following reply:

I can no longer maintain this code on my own. I need contributions to make any effort worth while. I no longer use this in my day to day work and have no intention to provide support all on my own. This project follows a very loose contribution process in that a simple pull request is all that is needed to be given commit access. If you want a feature or have it upgraded to the latest version of Redmine or Rails I ask that you make a Pull Request with that change so that others can also benefit.

Redmine Equipment Status Viewer is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Rules

There are a few basic ground-rules for contributors:

  1. No --force pushes or modifying the Git history in any way.
  2. Non-master branches ought to be used for ongoing work.
  3. External API changes and significant modifications ought to be subject to an internal pull-request to solicit feedback from other contributors.
  4. Internal pull-requests to solicit feedback are encouraged for any other non-trivial contribution but left to the discretion of the contributor.
  5. Contributors should attempt to adhere to the prevailing code-style.

Releases

Declaring formal releases remains the prerogative of the project maintainer.

Changes to this arrangement

This is an experiment and feedback is welcome! This document may also be subject to pull-requests or changes by contributors where you believe you have something valuable to add or change.