...
- Please be sure to share your plans with the Library Simplified community on the slack (or via one of the weekly Developer Meetings) before embarking on any sizable development effort. This will ensure you achieve your goals in a way that is consistent with the SimplyE architecture and plans of the rest of the community. It will minimize the chances of a scenario where you have invested a large amount of time and effort into a body of code that does not fit in with the SimplyE architecture or the consensus of the community.
- Develop incrementally; try and implement and contribute a basic form of your feature as soon as possible, rather than aiming to implement a complete and 'polished' solution. This will help ensure you're on the right track with regards to the rest of theLibrary Simplified community and SimplyE platform. The sooner your code is part of the core code base, the less time you will have to spend 'chasing' the main code base, i.e. keeping your changes up-to-date with that core code base.
- Obtain the SimplyE code using GitHub (see also Development with Git). This will make code management much easier. It's very simple to do; see Developer Guidelines and Tools.
- Read Code Contribution Guidelines (this page) and
- Code Style Guide for Mobile and iOS if working on Mobile apps or
- Code Style Guide for Server to ensure you are following style guide conventions.
This will ensure your code is more likely to be immediately accepted as part of out-of-the-box SimplyE.
- Read for Mobile Developers if developing on the Mobile Apps
- Ensure that any third-party tools/libraries that you plan to utilize are released under compatible open source licenses. See the Licensing of Contributions187177104 section below.
- For Larger Initiatives/Codebases: If you are building out a much larger project, we highly recommend notifying the community of the work early on via an email to info@librarysimplified.org. This can help find collaborators or get early feedback. We also recommend you develop your project in GitHub, as it provides easier ways to review/collaborate with other developers.
...
| Info | ||
|---|---|---|
| ||
But, my code's not ready! Don't worry! Think of it like this: open source software development is like a conversation. The conversation has to start somehow. Here's what you can do right now: create a JIRA issue, explaining your idea, and make a new branch, using that issue number in the branch name. Now, commit your new code to that branch, and push it up to your fork on GitHub. Now, the conversation has already started, and people have a way to discuss your idea in a meaningful fashion–referring to the JIRA issue number, perhaps reviewing and commenting on your branch on GitHub. It would probably be a good idea to link to your work in progress branch from the JIRA issue, as it will make finding you work, and the process of reviewing it, easier. Before you know it, you'll be ready to make a pull request, and your work will already have champions within the DSpace community, all because you put it out there and made it available for review early. |
...