Find ways of engaging more with the community

[NSeydoux]

As discussed during a meeting, it would be interesting for the panel to enable more community engagement. Regular meetings should carry on as they are, because it makes it much easier to discuss about specification matters assuming a certain level of intimacy with the discussed concepts.

However, part of the specification success will come from its high-level understanding by the developers who create solid applications, and them being okay about the constraints coming from the specification. As pointed out during the meeting, some of that discussion will happen at the library level, and the library implementers (me being one of them) will be able to collect some feedback and bring it back in a condensed form to the panel. It seems that it would still be beneficial to establish a more direct communication between the community (not restricted to the developers) and the panel.

One way of doing so would be to dedicate some time (e.g. one monthly session) to Q&A with the community. This would inform a potential primer with what people expect, potentially collect use cases, and generally help shared understanding of authentication issues in Solid. Such sessions could (and in my opinion, should) be announced in advance on the forum and Gitter channels, so that we can prepare to answer some questions, for instance by creating some pedagogic support that could be later reused. For instance, I created a while ago some slides to talk about some aspects of Solid (for instance during a n academic winter school, and I'd be happy to update them/create additional animations around topics discussed.

Do you agree this is something we could give a shot at, and do you have additional/alternative suggestions on how we should approach this ? Also, I'd be interested in the opinion of some members of the DEI panel, which could have very interesting insight on making these sessions as accessible as possible (@MarrelleBailey, @KyraAssaad, @jeff-zucker ?)

[woutermont]

Personally, as a Solid library and application developer, some of the main hurdles of engaging with the panel(s) are

• having not enough time to follow up on all the panels, repos, issues, fora, channels etc. next to actual developing; and
• input having no effect, since a first consensus seems mostly to have been reached very early on already (and assuming a certain level of intimacy with the discussed concepts for better or worse seems to imply assuming better insight than people with less time to follow up).

Also, there is a.f.a.i.k. no easy way to figure out why past decisions were made. Neither meeting notes, nor issue listings, nor gitter channels read or search very well. Apart from anecdotal summaries from people who were somehow involved, there seems to be no way to get an overview of which pros and cons were the rationale for a decision. This of course perpetuates the fact that some people have (increasingly) more intimacy with the subjects.

[acoburn]

@woutermont I would emphasize what was suggested above:

One way of doing so would be to dedicate some time (e.g. one monthly session) to Q&A with the community. This would inform a potential primer with what people expect, potentially collect use cases, and generally help shared understanding of authentication issues in Solid.

I would encourage you to attend such a session

[woutermont]

Of course, I would be glad to have such Q&As! My comment was definitely not meant to oppose that idea, but rather to add my two cents, based on personal experience, on what could affect the level of engagement addressed in this issue. (Specifically with regards to the Q&As, though, I doubt whether such a format would address any of the points I raised.)

[KyraAssaad]

I think this would complement our initiative to bring more transparency and understanding of the various Solid teams/committees/panels undertaken in solid/deit#18

WRT the reply from @woutermont

no easy way to figure out why past decisions were made. Neither meeting notes, nor issue listings, nor gitter channels read or search very well.

It might be a good idea to start a public-facing decision log. I wonder if a TL;DR summary after meetings would be beneficial as well. Just some thoughts to consider.

[jeff-zucker]

I very much agree with all of comments above. What I would find most useful is a frequently updated "score card" which basically lists all features and categorizes them as definitely in, definitely out, still thinking. The idea of a monthly meeting between implementers/panelists is great. I suggest that it be moderated by an implementer and that the focus be on answering implementer questions rather than simply describing what the panelists have accomplished. In terms of DEI, I think the key thing is to assume a low level of understanding and of familiarity with terms. Precision is key to writing the specs, but keeping things as simple as possible is key to broadening the audience.

[MarrelleBailey]

I would second the agreement. I think Q&A or an informative session will be very beneficial for others outside of the panels to attend. I really think it will help others to understand how they can contribute fully and what's going on. As for DEI, we can touch on this subject during our next meeting. Since we have an issue already raised, it will be good to ensure we make progress. *Marrelle Bailey – She/Her, *Communications and Community Organizer Contact | 210.317.4752 (M) Connect | *LinkedIn* <http://www.linkedin.com/in/marrelle-bailey>, *WebID* <https://marrelleb.inrupt.net/profile/card#me>, *GitHub <https://github.com/MarrelleBailey>* Explore | *www.inrupt.com <http://www.inrupt.com/>*

…

On Tue, Sep 7, 2021 at 1:10 PM Jeff Zucker ***@***.***> wrote: I very much agree with all of comments above. What I would find most useful is a frequently updated "score card" which basically lists all features and categorizes them as definitely in, definitely out, still thinking. The idea of a monthly meeting between implementers/panelists is great. I suggest that it be moderated by an implementer and that the focus be on answering implementer questions rather than simply describing what the panelists have accomplished. In terms of DEI, I think the key thing is to assume a low level of understanding and of familiarity with terms. Precision is key to writing the specs, but keeping things as simple as possible is key to broadening the audience. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#192 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APZ66YFCPLBQV5EVOLQT5BLUAZIR7ANCNFSM5DQVOBEQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

-- This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged, confidential and/or proprietary information. If you are not the intended recipient of this e-mail (or the person responsible for delivering this document to the intended recipient), please do not disseminate, distribute, print or copy this e-mail, or any attachment thereto. If you have received this e-mail in error, please respond to the individual sending the message, and permanently delete the email.