maintain information that must be know by each members

[benoitc]

Proposal:

make it easier for people that get a role in the foundation (board, members, contributing members, chairs...) to have a place where they can look at to know on what they have access to, what documents they can use ... This would ensure anyone know about what they can expect and check if everything is available for them. The othe rinterrest for tus is to have some kind of checklist/

This place should be contextualised based on the roles the member have . Ie. only useful information that target him can be found there.

Example of informations:

• mailing lists a member is subscribed
• optionnal mailing lists (mailing lists a member can opt-in/opt-out)
• documents they can acess
• where they can get some data relative to their roles r their membership
• where they can post/share some informations (to detail, but for example where to send a report , how it works)

How to do it & questions?

There is a mechanisme right nthat can display a link depending on the member role. I propose to extend it to add a link to a static content that can be updated easily.

The issue is how to have the content of this space kept private/contextualized (we don't want to have anyone know some mailing lists or other documents are existing). Is this "easy" to add? What would be the appropriate way to do it?

Also when a member register, we should be able to point it to this space so they are aware abut it. Can we have a welcome kit attached to the mailing list for it?

[starbelly]

There's quite a few things in this issue, so let's start with some of the bullet points to begin with :

mailing lists a member is subscribed

I suppose this would just show whether you are subscribed to the mailing list or not, is that correct?

optionnal mailing lists (mailing lists a member can opt-in/opt-out)

This would be a toggle. Note you can currently do this in wildapricot, but it would be a nice-to-have if you didn't have to. Is that correct?

documents they can acess

We need documents in well defined places for this. Maybe you're thinking various reports, etc? Is that correct?

where they can get some data relative to their roles r their membership

Are we talking about what perks you have as a member?

where they can post/share some informations (to detail, but for example where to send a report , how it works)

Now this one is interesting as this is something that came up in marketing, but specifically around allowing members to have profiles with contact details, etc. ala what the PSF does. I'm interested in digging into it more, may need to be a focused issue though. What reports would member sends in though?

I'm going to pause there.

[benoitc]

I'm not sure why there is a need of to enter in the details of which information we can make public.

To clarify it can be any information a member should know they have access to depending on their role. We all agreed during the last meeting it was something wanted with the goal of making the process less "organic" and more "organised". It is also based on the least surprise principle. A member shouldn't discover by accident a content they have been subscribed or they have access to. Instead a member must be able to know pretty easily on one place what they can do or must know.

For example a member must know tha it is subscribed to a mailing list and what are the mailing list they are suposed to/can have access. But this is just an example. (we can discuss in private about some). It is also about documenting for each member depending on its role where they can find any information/contact/... .

To take a concrete example (where everything is public which make it simpler) :

• https://community.apache.org/newcomers/

by roles:

• https://community.apache.org/committers/index.html
• https://www.apache.org/dev/

or more generic:

• https://www.apache.org/foundation/how-it-works.html

Some informatons may need also ti be private. So we need a way to have sections only displayed for a member or a role.

Questions related to it:

• Do we have already the code to add such "private" content ?
• What is required for?
• Can anyone without entering in elixir code can do it?

Any guidance on these ^^ would be helpful to build a prototype.