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:
Avri Doria <[log in to unmask]>
Reply To:
Avri Doria <[log in to unmask]>
Date:
Sat, 27 Sep 2014 23:42:26 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (103 lines)
Hi,

I still believe that the two applications processes

- to join the NCSG
- to join a constituency

Should be completely de-coupled.

To link them gives the impression that joining a constituency is the
norm and is an expectation is not a requirement.  It isn't.  It is an
extra membership that one should consider carefully once they have been
a NCSG for a while.

I do believe that there should be a single database with sufficient
access control to allow anyone in the world to see who is a member of
the NCSG and of any of its constituencies to meet transparency
requirements, with all other information restricted to the member and a
secretariat function.

avri


On 27-Sep-14 16:07, Sam Lanfranco wrote:
> Rafik,
> 
> Thanks for the useful questions and comments, and thanks to Tapani for
> his comments and his expertise. Rather than making a long response I
> would like to extract the key points [numbered] for follow up.
> 
> The objective is to manage these two processes while making NCSG and its
> constituency groups, best practice users of the Internet to. This will
> reduce administrative demands on the various executives and volunteers,
> freeing up more time to deal with substantive and policy issues.
> 
> One overarching issue has to do with how much ICANN support and
> involvement does NCSG want. Is it is an issue of trust, of efficiency,
> or of optics that suggests that little be hosted on ICANN servers? This
> needs to be discussed, and decisions arrived at. There are pluses and
> minuses whichever way one goes here. At the moment there are at least
> three independent server sites support NCSG and constituency services.
> 
> 1.We are in agreement with the idea that there should be one application
> form for NCSG that clearly states the constituency (NCUC/NPOC/neither)
> membership options. The form can reside on NCSG, NCUC and NPOC websites
> and report back to admissions email boxes. With regard to application
> improvements, there is no suggestion for over engineering, and in fact
> the opposite. A clear and concise application form will expedite
> application by interested parties, and expedite the admission processes
> at both the NCSG and constituency levels.
> 
> 2.Glad to hear that application improvement is being discussed,
> including a review of appropriate fields for the admission process, and
> what fields may be needed by NCSG, NCUC and NPOC. The key point is that
> fields should serve both the admissions process and the ongoing work of
> NCSG and the constituencies. Proposals for changes here (record forms
> and fields) should be shared with NCSG members to gather member feedback
> and draw on member expertise.
> 
> 3.With regard to maintaining the membership database:Best practices for
> maintaining the membership databases should put membership updating in
> the hands of members. While NCSG and the constituency groups may always
> have to chase laggards with faulty membership data, the process should
> have self-administered membership profiles, to facilitate ease of member
> access and to free up executive time and talents for more important work.
> 
> 4.The aution not adding fields not directly related to applications or
> aimed for specific purpose of course makes sense. Fields can be added
> when parts of the database are imported, for local (NCUC/NPOC) use. One
> way to facilitate that is for member profiles to contain fields for more
> information than just what is on the membership application. This
> doesn’t burden the application process, facilitates profile updates, and
> doesn’t take up NCSG executive time.
> 
> 5.The question of where to host the membership database and services is
> important and part of the overarching issue referenced above. Hosting
> it, or not hosting it at ICANN, has maintenance implications, access
> implications, and possibly political (optics) implications.
> 
> 6.The issue of database access is not complicated. Below the high level
> editing access, there can be only edit/view/export  access. NCUC and
> NPOC can export some/all of the database and add whatever they need. The
> NCSG Charter makes the NCSG EC and Chair responsible for maintaining and
> updating the membership database, but that does not mean that they
> should use valuable EC and Chair time to manually do what is an
> administrative task. However that is done, membership profiles would
> help. The current process of having members update records by contacting
> the NCSG chair is needlessly burdensome and inefficient.
> 
> 7.With regard to where profiles should reside, that doesn’t really
> matter. The prior issue to be resolved is what services should be
> mounted at ICANN, or elsewhere, and how profile access should be
> managed. The profile approach respects the KISS principle, gives more
> power to the stakeholder, and reduces labor demands on the executive and
> administration.
> 
> The overall goal is to do these things efficiently and effective, and
> free up executive and volunteer effort to deal with policy and other
> matters of substance.
> 
> Sam L.
> 

ATOM RSS1 RSS2