[This discussion has mostly been continued in other threads on the koha-devel list and in threads related to RFCs on this list.] At an earlier point in the discussion, we may have lost sight of a basic premise under which Koha has been developed even if has occasionally been neglected by a few people from time to time. We want everyone's good contributions to Koha. We do not want any patches to fall on the floor and become lost kittens. We have demonstrated that the collaborative open source development model works by our ability to produce software which is more useful to more people than what any small group of us would be able to create working in isolation, despite all imperfections. Most importantly, the free software license gives each of us the right to take that collaborative effort and change the code to suit each of own preferences which the collective effort has not yet met. Including individually modified code within the collaborative effort helps everyone, especially whoever has made the modification. Having given a reminder about the usual case, this discussion is about what happens when there are collaboration conflicts. We hope to resolve collaborative conflicts in a manner which encourages the inclusion of each of our preferences within one larger collaborative work, thus avoiding the need for individual implementations to use different code. Remainder of reply inline: 1. DECISION TAKING PROCESS. On Wed, November 10, 2010 18:07, david@lang.hm wrote:
the problem is that you are asking for a binding decision. open source software projects really don't work that way.
I agree with the basic point which David Lang is making. However, there is some difference between binding decisions and obtaining a reasonable consensus.
if it's useful to a library (or if a library thingks it would be useful), there's probably very little that would be rejected based on the description (what would show up in an RFC)
when it comes to the implementation, it's primarily a matter of taste, and there you have a lot of people who can object to the implementation, and they can object at any point up to (or even shortly after) the point where it is merged.
With or without a consensus, if some patch is appropriate for Koha and would not disrupt other past or present development, then there should be no formal reason not to include such a patch in the general release. Patches should ideally be tested for approval by people independent from the original author of the patch. 2. ROLE OF RELEASE MANAGER.
the RM makes the final decision on if the code is clean enough for the RMto be comfortable shipping it.
The release manager is elected to unify work for a particular release and to be mindful of any schedule for that release. While the release manager should be subject to persuasion from reasonable arguments, the release manager needs to be able to exercise final control over what patches are included and how they are included to adequate unify everyone's work within the context of any schedule.
you may be targeting a feature at 3.6, but there is no way that you can get assurance that it will be accepted into 3.6 this early in the process. depending on how the code works, how it's written, and how comfortable the RM is that it will work and be supported, it may get into 3.6, or the 3.6 RM may decide not to accept it at which point you should then try to either convince the 3.6 maintainier that he's wrong, or wait for 3.8 and try to convince that RM.
[I think David Lang meant RM (release manager) when using 'maintainer' in the previous sentence. Release maintainer is a similar but different role for the current stable release.] 3. CORRECTING DECISIONS.
I know this is not what you are wanting to hear, but this is one of the differences with open source projects, there is not the same commitment to prior decisions that you see in closed source projects.
All decisions should always be subject to open minded consideration in any context. Rethinking decisions allows for recovery from past, present, and future mistakes. Some decisions are more difficult to effectively change than others, such as the choice of programming language for the project. [This example is merely a good one and not a subtle argument for or against using work from any particular programming language.] Free software projects provide freedom to modify the code locally instead of the tight control of the proprietary development process. 4. CODE READINESS.
This is especially true when doing time-based releases. If a feature is 'ready' it will be included, if it's not 'ready' it won't be. 'ready' can include a lot more than just 'does the code work', it can include style, taste of the implementation, documentation, support concerns
Any minimal sense of readiness for patches should include running, usable implementation, and not creating uncorrected problems for other features. David adds style, documentation, and support concerns as important criteria which may be the next most important concerns but which I do not think should be grounds for not including a patch. The last point for minimal readiness about not creating uncorrected problems for other features is the difficulty which I understand has brought this discussion forward. Features might include anything from security standards to specific user functionality.
(if you are submitting something that nobody else thinks is very useful, but the community has concerns that you may just drop off the code and disappear leaving them to maintain the code the community will be less willing to accept the code)
The community should be happy to have good well written code 'dropped off' even if a vested interest in maintaining code would be preferred. If a patch is sufficiently useful, someone is liable to come forward to maintain it and and improve it. 5. COMMUNICATION.
as you develop the feature, maintain communication. as you make design decisions let people know about it. as soon as you have something that works (however imperfectly and unpolished) publish what you have so people can look at it.
It is the responsibility of those developing something for Koha to introduce it early and often prior to and throughout the planning and during the implementation of the work. Developers should contact anyone and everyone with whom it may be useful to consult for comment and criticism. Those with an interest in particular aspects of Koha have an obligation to give attention to development announcements on the koha-devel mailing list. Ignoring well publicised: sufficiently detailed RFCs; implementation strategies; and posting of running code might reasonably be interpreted as the absence of an objection. However, it is the obligation of developers to do more to encourage comment if there has not been any comment. Developers need to take comments which they receive seriously. People need good reason to believe that their comments may be liable to have a meaningful effect on actual development to have sufficient incentive to take a close examination and comment well. 6. CAREFUL RESEARCH AND PLANNING.
there is no point past which you can rule out major redesign requsts. It may be that after you have things working someone will notice similarities with other code and ask you re refactor things to better share code.
Anyone might identify a problem at any point which may not have been previously apparent. A developer has an obligation to research and plan an implementation carefully to avoid the risk of others making a late discovery of a problem which the developer could have readily identified earlier by taking more care in advance. 7. SHOWING COMPATIBILITY.
on the other hand, just because someone asks you to make a change doesn't mean that you must make that change, even if it's the RM. as the person writing the code you have a fair amount of power. you can argue back on why you don't want to do so. don't overuse this power, if things get heated it's playing a game of chicken with the community, but if the request is something that's really a problem for you, push back. If it's a matter of not having time in this release, you may be able to negotiate 'accept this as-is and I willre-write the functionality as you ask and have it ready for the next release', this sort of thing requires that you have built a reputation with the community so that they can trust you, and that the changes that are needed are mostly (if not completely) transparent to the users.
Someone may comment that a prospective development conflicts with existing features or other current development. If a developer believes that the presumption of a conflict is mistaken, it is the responsibility of the developer to show how the prospective development would not create such a conflict. 8. REFACTORING OR REWRITING TO AVOID COLLABORATIVE CONFLICTS.
in the case of alternate search capibilities, the initial implemenation may be a either/or approach where you completely replace the existing search. a second cut of the implementation may re-write the search interface to be more general and less tuned for either specific search option. a third cut of the implementation may refactor both search implementations to share a lot of their code and only differ in the routines that call the search engine. a fourth cut of the implementation may include expanding this to support some additional search options to demonstrate that the search interface is now generic enough to be useful going forward.
Well designed code should not need to be rewritten but merely refactored for some functional purpose such as abstraction. Refactoring to avoid conflicts with other development may be necessary for collaboration to go forward. [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783