NCSG-DISCUSS Archives

NCSG-Discuss

NCSG-DISCUSS@LISTSERV.SYR.EDU

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Tapani Tarvainen <[log in to unmask]>
Reply To:
Tapani Tarvainen <[log in to unmask]>
Date:
Sat, 27 Sep 2014 19:57:18 +0300
Content-Type:
text/plain
Parts/Attachments:
text/plain (78 lines)
On Sat, Sep 27, 2014 at 09:13:52AM -0400, Sam Lanfranco ([log in to unmask]) wrote:

> *1. How would data base additions feed directly into our (NCUC)
> website listing of members? *
> Ideally, and easy to do, there could be a single operation
> (extracting a subset of a membership spreadsheet (or database) that
> produce the NCUC list.

That's what I had in mind, and indeed it is how NCUC website now works:
while the database is now in the same machine, it is used in such a way
that it could be moved elsewhere without any changes (apart from
setting the database location in where it's called).
If you want spreadsheet-style it is easy to extract CSV files
from the database, but I think it'd be better to have a simple
web interface for browsing the database (or subset thereof) directly.
(For NCUC there already is a script to produce voter list in the form
ICANN voting system needs them.)

> **2. How to handle subscriptions to mailing lists?*
> I have run dozens of mailing lists (using listserv like Milton from
> Syracuse) and as a principle we always have someone from the
> stakeholder group with co-manager/moderator authority. That should
> be the case here. For the brief time I was NPOC membership chair I
> had great difficulty determining the subscriber list for npoc-voice.
> Automating population of mailing lists from a membership spreadsheet
> is a bit of work.

But almost trivial from a real database and mailing list software
that can be easily scripted (like Mailman running NCUC's lists)
and with direct access (not just web interface!) to it.
If the database is considered to be the definitive source of
addresses and list memberships, syncing them over to Mailman
takes about three lines of code (been there, done that).

It could be done with LISTSERV(tm) as well, but it's somewhat
more complicated (especially without admin level access to
the machine running listserv). Ditto with ICANN-managed lists,
easy automated updates would require level of access they may
not want to give us.

> **3. How to compose/verify voter lists for elections?*
> The key issue is that an eligible voter list be accurate. That
> starts from an accurate overall membership list, and accurate
> mailing lists so that a step involving qualifying voters (just a
> simply email response) works as it should. This is why I suggested
> that NCSG members have access to a membership profile page somewhere
> (within the ICANN dashboard?), a profile page is first populated by
> data from a successful application, feeds the membership database,
> and can be updated by the member. This is useful when a member is
> not just from an organization, but formally represents that
> organization and may be replaced over time. Profiles could be
> updated, with notice of update sent to those who maintain the
> mailing lists. The update would get captured to NCUC and NPOC with
> periodic/frequent NCUC and NPOC membership updates from the master
> NCSG membership list.

That's close to what I had in mind, but I'd tie the profile page
directly to the master database. That way it'd be always up to date,
any changes members make to their data would be instantly visible
to anyone viewing the database (including public lists in websites).
I'm not sure how easy that would be if se use ICANN dashboard
(again, depends on what kind of access ICANN would give us).

As for verification, the scheme I wrote last year for NCUC worked
pretty well, although it could be automated even more.
Something like this:

A specified time before election (or triggered manually if preferred),
send an automated email to all members, showing their current details
and including URLs (buttons) to click either to just confirm their
activity or to change their details. A second reminder could be sent a
specified time later to those who haven't replied to the first. And of
course Chairs (&c) could at any time view the status and if desired
take manual action as well.

-- 
Tapani Tarvainen

ATOM RSS1 RSS2