Development
From DocMGR
Contents |
Licensing
From 0.54 to 0.57.3, DocMGR was under a dual-licensing scheme requiring all contributors to sign a waiver which released their contribution into public domain. This is no longer the case, as DocMGR is now GPL only (version 2). You can click on Licensing to see the full copy of the license testing
Contributing
Anyone is welcome to contribute. However, I do ask they have a sourceforge account and possibly create their own wiki account here. I want to encourage lots of discussion between all developers here and in the sourceforge developer's forum. In the past, I required all patches to be submitted to me for approval. We're going to go the opposite way now. If you want to contribute, please let me know and I will create an svn account for you at svn.docmgr.org. You will be responsible for checking in your own patches. Because the policy is more open, it's up to the contributor and the community to make sure their code is as high of quality as possible. DocMGR's module system allows for clean separation and organization of code. We should do our best to keep it that way.
Ways to contribute
DocMGR doesn't just need code, we need someone to monitor the forums, update the documentation on the website, create themes, etc. I basically want to pass this project onto the community so my contributions do not make or break the project. There are so many requests of features that people want that I just can't keep up anymore. But, this project has a very solid code and community base, so I feel it can thrive with the community's support.
Having said that, I do want the active contributers involved in what new features will make it into the release. Having people randomly add things all the time could get messy. So, the developers forum, the bugtracker page, and the feature tracker page on sourceforge will be invaluable.
What we need (No particular order)
- an xml based api. DocMGR's strength is in the backend file storing and retrieving capabilities. With an xml-based api, we could easily access docmgr from outside applications for file storage and searching. I don't really want to go the way of SOAP, although I'm not totally against it. It just adds a level of complexity that we don't necessarily need. I also think that docmgr's searching, browsing, and uploading utilities should probably just be front-ends for the api anyways.
- WebDAV enhancement. Someone with more patience than me needs to take a crack at WebDAV. It works fairly well now, but webdav acts differently for all clients. We get a lot of complaints regarding our webdav implementation, so it needs some work.
- Maintain the forums, checking for spam and whatnot
- Bring the documentation up to date.
- An installer that automatically configures apps and checks for required dependencies.
- A live CD for easy testing
- Updated FAQ page and Todo list
- Reorganized browsing. I'm not quite sure about this one yet. But, I think the browse tree should get the entire left column. The search allows dynamic filtering of whatever collection I am browsing or does the traditional entire tree search. It should probably be ajax based to automatically update the tree.
- updated e-dev (this one's mine). I need to update e-dev so it possibly handles ajax based html POSTs and includes some other goodies.
Great! What do I do now?
Email me at elawman@eastwestp.com and let me know how you want to help.
