I'm disappointed that no OpenLibrary or Internet Archive staff ever replied to this thread. I guess that shows where community communication ranks in the priority scheme of things.
Below are some comments on the replies from Karen and Charles (thanks for taking the time to reply!). Perhaps reviving the thread will stimulate discussion. On Mon, Aug 24, 2015 at 5:37 PM, Karen Coyle <[email protected]> wrote: > > On 8/24/15 1:57 PM, Tom Morris wrote: > >> What would it take to convince IA/OpenLibrary that a public bug tracker >> is a critical part of the open source development process? >> > > Tom, IMO the issue isn't about bug tracking but staffing and costs. There > is virtually no staff time dedicated to OL, so the question of being open > source and tracking bugs is somewhat moot. Even an open source project > needs to make use of some human time. With the project essentially > de-funded, having a "crowd sourced" bug list means that the bug list will > grow, but few bugs will be addressed. It took something like two years to > get OL re-indexed, and that seems like a no-brainer. > > As for it being open source, I'm not sure that is indeed the current > thinking. Even if it were, it appears to me that the project lacks the > tools needed to make code contributions possible (e.g. the test > capabilities that I have mentioned before). Perhaps step one is to clarify > whether the project is indeed intended to be open source (not just "source > code lives in github"). That could help us manage expectations. If the intention is for OpenLibrary to abandon it's 7+ year open source legacy, that would be certainly be a much bigger issue than whether or not there's a public bug tracker. Having read writings by Aaron, George, and other early OL leaders, it was certainly my impression that the choice of being open source was intentional, not an accident, but I could be mistaken. Cultivating a vibrant set of open source contributors could actually *reduce* funding requirements, improve responsiveness, as well as overall community engagement. Ben, Charles, and others have already contributed a number of bug fixes to OpenLibrary. Willingness to promptly review, merge, and deploy bug fixes would encourage others to contribute and provide a low cost way to leverage scarce development resources. A recent email highlighted the 4 years worth (!) of community provide bug fixes which are being ignored at https://github.com/openlibrary/bookreader/pulls. The first of the epub issues, which have been around for years and years, finally got addressed because two community members isolated and fixed the problem. Public issue trackers aren't just for the technical community. They also help give the general OpenLibrary community which provides crowdsourced metadata insight into the issues which hamper their work and the progress which is being made to fix them. Community engagement drives not only in-kind contributions of programming & data-entry hours, but also real dollars for things like the recent year end funding drive. Engaged communities contribute more in all dimensions. Disconnected and disenfranchised communities don't contribute in any way. Grant writing organization also have a reasonable expectation that the grantees will conduct themselves in a way aligns with their publicly stated values and the values that they claim on their grant applications. If things like transparency, communication, public dissemination of open knowledge, etc become perceived as buzz words which are paid lip service rather than core values, it could easily reduce funding levels from granting organizations. On Fri, Sep 18, 2015 at 2:42 AM, Charles Horn <[email protected]> wrote: > > Here are my thoughts on the Jira and Github situation, I don't think > having both is necessarily a sign of a problem in an open source project. > I agree. The main problems are that 1) the change was made years ago with no notice and 2) there's no way to access the canonical issue tracker (Jira). > Jira is a tool for tracking employee time spent on projects, development > velocities and other internal and cross project metrics, not just issue > tracking. It makes sense to me that the IA would have an internal system to > track the work they are prioritising for devs who are likely working on > many things, and not have this open to the public. > Jira can be used in lots of way. If it's used to manage scrums as well as track issues, access to the scrum boards can almost certainly be restricted, if that's deemed important. Jira also offers all sorts of options for multiple projects, different security levels, etc. > I have worked in places where we used Jira extensively and hosted open > source projects on Github too. There is an extra effort to keep the two in > sync if there is demand for it, but I think Github is always an appropriate > place for community raised issues to be tracked, if the project is publicly > hosted. It is up to IA to manage how that relates back to their internal > systems. Hopefully community contributions are considered valuable and the > extra effort of potentially double tracking in separate systems will be > worth it for IA. > There are many different ways that things could be configured and at least a few of them are likely workable solutions which would provide both a shared communication space as well as provide for any perceived privacy needs (although, I must admit, I don't understand the need for secrecy in a non-profit dedicated to knowledge dissemination). > Having an idea of IA priorities in regards to Open Library would be > helpful, as would a clear set of contribution guidelines, but as a > community we can put forward our own ideas too. > Yes, that would be great. As would the ability to provide input into those priorities (assuming that meeting the needs of the community is a goal at some level). I'd love to hear where the powers that be stand on this stuff. Is there some kind of edict from on high that prevents communication about plans, priorities, intentions, anything? Tom
_______________________________________________ Ol-tech mailing list [email protected] http://mail.archive.org/cgi-bin/mailman/listinfo/ol-tech Archives: http://www.mail-archive.com/[email protected]/ To unsubscribe from this mailing list, send email to [email protected]
