[Koha] Proposal to form Koha Technical Committee

[Thomas Dukleth]

[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 at 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