We need a membership list

[JamesBelchamber]

Currently there isn't a member list that can be used by other parts of the infrastructure. We need a centralised, extensible way to store members and their details.

[daubers]

beware of data protection with that information. The reason it hasn't been done before is that the legal issues around are miriad.

[JamesBelchamber]

Yup. But, we do have the data anyway, it's just potted about. We definitely need to consider what needs to be stored but not directly accessible, what needs to be encrypted, and what definitely doesn't need to be stored.

[Gavatastic]

I will look into data protection issues - i have some exposure to this at work , and at least know how to find the guidance. Will see what I can figure out and report back.

[Gavatastic]

Here's a link to the 131-page 'Plain English' guide if anyone else is interested in reading too https://ico.org.uk/media/for-organisations/guide-to-data-protection-2-3.pdf

Do we think that it is 'just' this, or can anyone think of other regs/legislation that might apply?

[Gavatastic]

By my reading of this document: https://ico.org.uk/media/for-organisations/documents/1567/exemption-from-registration-for-not-for-profit-organisations.pdf

we may be exempt from registration on the basis that:

• a not-for-profit organisation is defined as: 'A not-for-profit organisation can make a profit for its own purposes, which are usually charitable or social, but the profit should not be used to enrich others. Any money that is raised should be used for the organisation’s own activities.'

and

• The exemption [from registration] applies to processing which is only for the purposes of:  establishing or maintaining membership;  supporting a not-for-profit body or association; or  providing or administering activities for either the members or those who have regular contact with it.

but that just deals with registration, not processing. I'll read on.

[JamesBelchamber]

Mike raised concerns about even implementing a framework for this before privacy issues have been addressed - an example was that he didn't want to see the same email address used across multiple rlab systems, or accounts from multiple systems tied together. We decided to put any implementation on hold until privacy issues are addressed.

[Gavatastic]

Agree that it should be put on hold until the issues are addressed. I suggest that rather than clogging up this system with a discussion about privacy, a #privacy channel is opened in Slack for us to kick the issues around.

[JamesBelchamber]

This really needs to be defined by RMS, not the members, based on their requirements (to get a grip on 'who a member is' and 'who the members are') and responsibilities (under, for example, the DPA). Once we've defined that we can build something, and once it exists we can talk about extending it (and what we want to expose when doing so).

Let's solve RMS's issues first with this, then see if we can solve issues the community have with it.

[alex-gibson]

Should we create a placeholder database with a few test cards on it? So that this project can have momentum and maybe be a spur to the member list project, not delayed by it?

Tapped on my mobile phone.

On 17 Mar 2016, at 22:17, James Belchamber notifications@github.com wrote:

This really needs to be defined by RMS, not the members, based on their requirements (to get a grip on 'who a member is' and 'who the members are') and responsibilities (under, for example, the DPA). Once we've defined that we can build something, and once it exists we can talk about extending it (and what we want to expose when doing so).

Let's solve RMS's issues first with this, then see if we can solve issues the community have with it.

— You are receiving this because you were assigned. Reply to this email directly or view it on GitHub