[Linux-aus] MemberDB is a great short term solution, but we need a broader rethink

[Anthony Towns]

On 19 January 2015 at 22:53, Neill Cox <neill.cox at ingenious.com.au> wrote:

> I'm interested in working on a flask and angular solution as I have skills
> in python and javascript. Unfortunately I have next to no php or drupal
> skills.
>
> If the concensus is that drupal is the way to go then I will quietly bow
> out and wish you the best of luck :)  I'm not being precious about this, I
> just don't think I am the right person to work on a drupal replacement.
>
> ​Flask rulez, php drools ;)​

​​
> On 19/01/2015 8:36 PM, "James Purser" <jamesrpurser at gmail.com> wrote:
>
>> If we're going to stick with drupal then I think the best option is to
>> use a drupal based membership management system, if nothing else, it
>> reduces the "walk in front of a bus" problem.
>>
>> As I recall from previous investigations the only thing that civicrm
>> lacked was the ability to hold elections.
>>
>
​"(1) Do everything in drupal, (2) keep people skilled in drupal around,
(3) ..., (4) (non-)profit" is a pretty reasonable approach. I had a quick
look at civicrm on the web, but didn't really understand what it actually
did; and it's not packaged in debian afaics, so my presumption is it's
fairly heavyweight and complicated (which you might translate as
full-featured and well-established).

An alternative approach LA ​could take for its systems is one more along
the lines of shell commands -- ie, an array of small, well defined,
single-purpose apps that interact only in very simple ways. That would have
the advantage that any one piece is fairly easy to swap out and replace
(because it's small and single purpose) and that in turn means it doesn't
matter so much if it's in a language that falls out of fashion.

If you took the latter approach, maybe you could run the technology
selection as a competition. Eg:

  1. we want a membership database
  2. it should allow:
        - new members
        - dealing with duplicate members
        - checking members are still interested
        - paid memberships
        - importing data from existing db (or reusing db directly)
        - using member info for other tasks (elections, email aliases, ...)
  3. prototypes/proofs of concept accepted during the next six months
        - probably with checkpoints so folks can see how the competition is
doing
  4. best entrant selected based on some combination of:
        - feature completeness as per (2)
        - simple, usable, documented API (to hook into other systems)
        - simple, understandable codebase (to improve later)
        - simple, maintainable packaging (keep admins happy)
        - membership vote on aesthetics (web ui, etc)

and

  1. we want an updated election system
  2. it should support
        - displaying results of elections from the previous system
        - running the council election (4x 1-winner, 1x 3-winner)
        - running elections for LUGs affiliated with LA
          (ie, not all LA members entitled to vote)
        - a nomination process
        - the ability to decline a nomination
        - running membership polls
        - auditing the results
        - authenticating against the membership database
  3. (as above)
  4. (as above)

​LA could encourage people to enter the competition by (a) offering a prize
(memberdb was originally funded by a grant eg), (b) ​offering useful
reviews of all submissions that can then be used as marketing material by
entrants.

Keeping a focus on "small, interoperable components" means that you could
just do the same process when wanting a new feature -- and accepting that
sometimes entries might just be modifications of the existing system,
sometimes might be an additional component, and sometimes might replace
existing components.

(I think that process is flexible enough that civicrm could win on its
merits, )

​(I would love to see an occassional competition like the above to see if
Xero can be replaced by a free software solution)​

​Cheers,
aj​

-- 
Anthony Towns <aj at erisian.com.au>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.org.au/pipermail/linux-aus/attachments/20150120/26cf193f/attachment-0001.html>