<div dir="ltr"><div><div>I have nominated many of the contributors to this thread for OCM for the 2016 Council Election and I encourage you to do the same. If I have missed anyone, feel free to nominate yourself on this basis.<br><br></div>The document prepared by Kathy has created much discussion on this list and I would like to see a transition from commenting to doing.<br><br></div>David<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 6 January 2016 at 11:50, Michael Cordover <span dir="ltr"><<a href="mailto:la@mjec.net" target="_blank">la@mjec.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><snip a bunch of discussion about Google Docs vs git><br>
<br>
FWIW, I think that this is the worst kind of bike-shedding. Before we<br>
have a discussion about what we should do in future, let's have a long<br>
discussion about what we should use to have that discussion. Blarg.<br>
<span class=""><br>
On Wed, Jan 6, 2016, at 10:19, Stewart Smith wrote:<br>
> Anthony Towns <<a href="mailto:aj@erisian.com.au">aj@erisian.com.au</a>> writes:<br>
> >> The existing Membership management tool, MemberDB is end of life and a<br>
> >> replacement is sorely needed. Some discussion has occurred towards this<br>
> >> goal, but momentum toward an outcome has not been sustained.<br>
> ><br>
> > I would say the momentum that was there was to set some criteria on what<br>
> > the replacement should do, then evaluate alternatives. Proposing CiviCRM<br>
> > as the right solution rather than doing that is exactly what killed the<br>
> > momentum, from my perspective...<br>
> ><br>
> > I think "end of life" is just standing in for a value judgement, not<br>
> > that there's an actual time limit on how long it can kept being used;<br>
> > ie it would be more accurate to just write "MemberDB is pretty crap in<br>
> > the author's opinion". Evaluating it against actual criteria would be<br>
> > better, of course...<br>
><br>
> or someone starting to make some small incremental improvements. Every<br>
> attempt at rewriting from scratch has gone nowhere, largely because<br>
> that's a whole bunch of extra effort.<br>
<br>
</span>Kathy Reid provided a working document to linux-aus on 2 Feb 2015<br>
outlining enhancements that would be required to MemberDB. That's at<br>
<a href="https://docs.google.com/document/d/1tyTA3Fj5J9XL2D7UTIxw46smXGrLM5J-fI4g6GxK9hM/edit?usp=sharing" rel="noreferrer" target="_blank">https://docs.google.com/document/d/1tyTA3Fj5J9XL2D7UTIxw46smXGrLM5J-fI4g6GxK9hM/edit?usp=sharing</a>.<br>
<br>
The key functionality of MemberDB that would need to be replicated in<br>
any other system (aside from everyone-provides things like sign up flow)<br>
is elections. MemberDB does this quite well, and meets some specific<br>
needs:<br>
<br>
1. the ability to run the whole process, including nominations,<br>
acceptance and candidate statements<br>
2. preferential voting<br>
<br>
The latest Launchpad commit to MemberDB<br>
(<a href="https://launchpad.net/memberdb/trunk" rel="noreferrer" target="_blank">https://launchpad.net/memberdb/trunk</a>) was 2011-02-04. Its underlying<br>
DAL is built on PEAR::DB, which has long since been superseded<br>
(<a href="http://pear.php.net/manual/en/package.database.db.php" rel="noreferrer" target="_blank">http://pear.php.net/manual/en/package.database.db.php</a>). A quick look<br>
indicates it was probably built for PHP 4, which was EOL in August 2008.<br>
<br>
If someone can take on making improvements to MemberDB, that's great.<br>
But it doesn't have the structure of a modern application, and it won't<br>
work within a modern development environment. I think it's unlikely<br>
anyone would want to maintain and improve it without a major refactor,<br>
or indeed rewrite.<br>
<br>
If we're going to work on that basis, we should consider whether we<br>
should be using one or more other tools. CiviCRM isn't perfect, and<br>
requires a Drupal base. It's a bit clunky, in part because it has a lot<br>
of functionality which is not immediately useful to LA. However, it<br>
gives all of the new functionality we need, and building in election<br>
functionality would almost certainly be far less effort than building<br>
the new functionality (in Kathy's document) into MemberDB. As a bonus,<br>
we can contribute that back to the existing large community of CiviCRM<br>
users.<br>
<br>
MemberDB was an excellent tool. It was state of the art when the last<br>
official release occurred, nearly 10 years ago. That we've been able to<br>
continue using it is a testament to its quality. However, it does not<br>
meet the current needs of LA.<br>
<br>
Regards<br>
<span class="HOEnZb"><font color="#888888"><br>
Michael<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
linux-aus mailing list<br>
<a href="mailto:linux-aus@lists.linux.org.au">linux-aus@lists.linux.org.au</a><br>
<a href="http://lists.linux.org.au/mailman/listinfo/linux-aus" rel="noreferrer" target="_blank">http://lists.linux.org.au/mailman/listinfo/linux-aus</a><br>
</div></div></blockquote></div><br></div>