This discussion thread has been silent since March, and I would really
like to bring it to some resolution.
To recap, I posted (at http://trunk.simile-widgets.org/) a proposed
release of exhibit 2.3 with various bug fixes and feature additions.
Concerns were raised that it was inappropriate to add features as this
would make it harder for e3 to achieve feature parity/compatibility. I
accepted this argument and formulated a proposal to exclude the
egregious feature additions from the release while including those bug
fixes I considered important. I've quoted that specific proposal below.
The discussion then branched into the broader topic of how to manage the
commit process, with stefano helpfully posting the proposed change for
review at http://codereview.appspot.com/5673046/ . But nobody has
contributed to that review, and several months ago the discussion ground
to a halt and nothing has happened since. I consider this a bad outcome.
I would like to bolster my revised release proposal below with the
argument that it is relatively low stakes. Surely the developer
community has migrated by now to exhibit 3. They should have little
concern about these compatible changes to e2, and none at all about
general commitment process since no further development will happen on
e2. My primary concern is for the *users* of e2 who will benefit from
these bug fixes (as well as a reduced dependence on the unreliable
painter service).
So, can anyone who cares weigh in? If nobody does, I guess that's a
sign that I'm free to make the decision on my own....
The specific proposal, quoting from my february 9 email:
You started winnowing; I will continue. This discussion was triggered
at, as you say, "this particular, odd moment in time". It has
broadened to cover much philosophy germane to long-term planning of
our commit/release process. But I think it will simplify to split
consideration of the present "odd moment" from the future planning.
Perhaps we can put to bed the current issue---what if anything should
be put into a 2.3 release---without wrestling with long-term questions.
I *think* that a lot of the objections you raise have to do with
offering new functionality. So let's consider winnowing the "new
functionality" parts of my proposed release. Looking over the stuff
I've put in trunk
(http://people.csail.mit.edu/karger/Exhibit/alpha.html) it would seem
that the following represent changes that do *not* offer not
functionality so won't raise problems being released
* rewrote xml, html, and tsv/csv importer (all have been there for years)
* map extension to use gmaps v3, canvas
* stable sorting in tables
* upgrade jquery to 1.7
* simileajax modified to use simile-widgets.org
* bug fixes
Then there are changes that clearly offer new functionality, so should
not be in the release:
* logging. it will be a nuisance to remove all the logging calls, but
we can remove the parameter test that turns them on
* data editing. this is a standalone extension, we can host elsewhere
Then there is a grey area. I hope these can be included in the
release as argued below, essentially because they are *minor*
* label property optional. this is a trivial change (create a label
if missing) that fixes an incredibly common inexplicable and
frustrating failure for novices trying to create exhibits.
* inline data view the <link rel=exhibit/data href="#data"> tag. This
is inarguably consistent with the semantics of the link tag, and fixes
another one of the most common complaints about exhibit (not indexable)
* inline data in body tags with ex:role="data" attribute. Yes. this
is a new feature. But it's very convenient (kind of necessary) for
people who cannot access the head, and I personally would like to
release it here as a way to promise it for E3
* two new example exhibits that demonstrate the data import methods.
While certainly new, they aren't part of the code at all, just html
documents, but are convenient for people learning about or testing the
tool.
On 2/10/2012 12:15 PM, Stefano Mazzocchi wrote:
On Fri, Feb 10, 2012 at 5:51 AM, David Karger <kar...@mit.edu
<mailto:kar...@mit.edu>> wrote:
As I tried to indicate in my last email, I'm actually quite
sanguine regarding whetever commit process the community evolves
going forward. There's no rush to figure it out and I'm sure I'll
be happy to follow it. In particular if I find it too burdensome
I can just stop coding. Also, this process will be focused on E3,
as E2 development is ending.
My *immediate* concern is the code I've *already* developed for
*E2* in the absence of any clear commit process. I'd like to
arrive at a decision about its disposition, one that hopefully
doesn't involve throwing it all away. I'm sitting on a (fait
accompli) bunch of code that I think will be of use to the current
users, so I'd like to incorporate it.
Fair enough, let's get practical and decouple the immediate needs from
the need for more explicit governance rules.
Here is what I would do:
1) move the existing svn "trunk" into a branch, say "branches/davidk_2.3a"
2) copy the "tags/2.2.0" release as "trunk"
3) tell people NOT to update their svn if they're running from trunk
until this conflict is resolved
4) create a diff between "branches/davidk_2.3a" and the current
"trunk" (which is now the latest released exhibit)
5) put the above patch up for review (for example, a very good one
that mimics the tool that Google uses internally is
http://codereview.appspot.com/, but any public code review places
would work)
6) collect suggestions from the community there on what part of this
patch should be "pulled" into trunk for an immediate release and what
should remain there up for further discussion on alignment with the
3.0 tree, governance and ownership rules, maintenance responsibilities
and what not
7) apply the community reviewed patch to trunk, release it as 2.2.1 if
there is no added functionality but only bugfixes, 2.3.0 if there are
additions in functionality as well but back compatibility is
guaranteed... if it's not back compatible, it shouldn't have made it
into the patch in the first place.
8) tell people the harmonization is done and they are free to update
from trunk again
8) whatever is left on the floor of the editing room will probably
need further discussions on where it should live, although my
suggestions would be against further development on a "vendor" branch
and rather use the github model instead, and that might require us to
move the mainline from svn to git, although it might not be necessary
since git can also talk to an svn repository.
The above process would give you increase vitality and freshness in
the mainline that you seek and reduce the impedance mismatch between
the agreed upon 2.2 -> 3.0 transition path and the currently proposed
2.3a "detour".
Now, granted, the devil is in the details and such a code review might
yield consensus that might not fit 100% your needs... at the same
time, it will bring confidence to the fact that this community can
self-regulate and protect its users interests, however varied they are
and will allow you a clear path that can be repeated in the future.
In fact, I would venture to suggest that using a review-then-commit
model might be much better suited for this project, considering the
variety of interests surrounding it and the different in skillsets in
terms of programming and backgrounds in production-quality software
engineering.
All the above will sound painfully convoluted, I'm fully aware of
that, but I don't see an easier way to resolve the current impasse in
ways that help everybody involved.
On 2/10/2012 3:33 AM, Stefano Mazzocchi wrote:
Allow me to add my 2c to this discussion, mostly out of personal
experience with having started, mentored and transferred
ownership and
control of several open source projects, some of which highly
successful and most of which still in existence to this day.
First, let me say that I see value in both sides of the
argument: this
proposed release is indeed a fork (and that is bad) but it's also
injecting new vitality into the project (and that is good).
One of the metrics I've used in the past to evaluate the health of
open source communities is their abilities to survive their
original
authors/promoters leaving. DavidH has beent he main
contributor for
Exhibit (and various other simile widgets like timeline) and his
participation is very much reduced. I had a much smaller role in
development but a bigger one in project/community management,
and my
participation is similarly reduced.
The principal reason why communities implode after the original
authors leave is what I normally think of as "thermal death":
without
a converging force, entropy kicks in and when it passes a certain
threshold, the project dilutes its social capital and fails to
convert
enough users into development contributions. The process is too
diluted to sustain itself and it decays.
My understanding of Ryan's strong reaction is a resonation to that
perception: David actions are in good faith but represent a clear
signal of entropy increase.... and show a path of entropy
increase and
dilution of cohesion and social capital.
The plan to split the release in patches that fix existing broken
behaviors from new functionality is wise and a good step
forward, but
the problems Ryan outlines are real and should be taken very
seriously: without an established and meritocratic process for
vetting
contributions and granting ownership to vested parties, there
is no
way this project will survive thermal death.
Before you think "governance rules" and drafting committees
and asking
for a grants to foundations to fund various get-togethers
around the
country to make it happen, let me just save you all that
problem and
propose you a simple one that would work:
1) use a distributed version control system for contributions
where
anybody can push their own tree, and the main line pulls from
what the
stakeholders consider appropriate (by simple email voting, lazy
consensus and majority ruling, no veto power).
2) stakeholders can ask new stakeholders to be granted that
status by
nomination and majority ruling
So, if the majority of stakeholders believes that logging
every action
in every page that embeds exhibit to an MIT server is a worthwhile
feature to have, it will be pulled into the main-line and released
officially... if not, it stays in a side branch, away from
where it
can do damage if mis-used or mis-understood.
But at least, by virtue of a public process to propose
additions to
the mainline, there is the possibility for review... which is what
David proposal lacks and that is causing Ryan's production
engineer
spidey sense to tingle.
I understand why this will not sound appealing to David: why
go from
the ability to commit code as needed to a process that is more
difficult, time consuming and potentially less appealing for
external
(and shy) contributors?
Because if not this project will splinter in many different
"vendor"
branches (one as an MIT research platform, one as a Zepheira
product,
one as a Library of Congress publishing system and so on) and the
Exhibit brand will be diluted, users will be confused by the
incompatible codebases, the ability to turn their usage into
potential
contributions will be drastically reduced, along with the
potential
for each vendor to share maintenance costs with one another.
As a result, the ability to promote Exhibit as a funding
substrate,
software product or publishing system respectively will
considerably
degrade if unity is not promoted and maintained as a core value.
This is why, if I had to pick a side, I would side with Ryan and
focusing on increasing sustainability instead of increasing
momentum:
mostly because a valuable and healthy/sustainable project will
find a
way to increase its momentum, while a project that increases
momentum
by splintering to shed inertia will have diluted its social
capital
with that action, potentially so much that it could go below the
threshold that makes the project appealing and find itself slowing
down its momentum irreversibly.
--
Stefano.
--
You received this message because you are subscribed to the Google Groups "SIMILE
Widgets" group.
To post to this group, send email to simile-widgets@googlegroups.com.
To unsubscribe from this group, send email to
simile-widgets+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/simile-widgets?hl=en.
