Add W3C Solid CG Charter #323
Conversation
|
-1 Discuss first https://lists.w3.org/Archives/Public/public-solid/2023Jul/0002.html |
|
@melvincarvalho not sure if you have noticed that tomorrow's Solid CG weekly meeting has this PR as one of the topics https://lists.w3.org/Archives/Public/public-solid/ |
|
Hi @elf-pavlik, This is a significant change impacting the entire community group. Keep in mind, only a minor portion of the group frequents the other platforms you mentioned. Let's finalize the WG Charter while concurrently strategizing on advancing the CG, ensuring full group awareness and consensus. Kindly refrain from merging until that point. |
|
Perhaps one addendum that could be interesting is how the CG relates to the WG w.r.t. tasks, discussions ... |
|
I agree that reviewing and defining the CG charter is a necessary step. @csarven - thanks for starting the process. I believe that we are in a new phase of Solid and that the Community Group should redefine its emphasis to fit that shift. We need to put more emphasis on the word "community". The group should serve to not only facilitate the creation of the specs, but should now also focus on the dissemination and use of the specs. A dialogue between spec writers and the wider community is needed so that the spec writers can hear use cases and get implementation feedback. It is also needed so that those using Solid can find the current state of the specs as they relate to their work, to get a source of networking with similar projects, and to make their contributions known to the world. I also believe that the list of technical topics Sarven provides should be supplemented with topics exploring the social impact of what we are building. While interoperability and the other technical underpinnings are key, we also need feedback about how decisions on those issues impact how Solid plays out in the real world. Eventually we might have break-out discussions or sub-groups doing this for various verticals. Including these kinds of community and social impact feedback will make the specifications stronger and also give an opportunity for more people to participate in the CG without feeling they need to be a "specifications person" to participate and contribute in an ongoing fashion. This will hopefully broaden the base of the currently mostly elite group who participate on a regular basis. As we move into a phase in which real world initiatives will increasingly be appearing, we should gain feedback from those initiatives and support and help publicize them. This is how we grow a community and an ecosystem. So I like most of Sarven's proposal as it relates to work supporting spec writers. I am in favor of adding support for developers and users into the mix which would probably necessitate additional co-chairs for those aspects of the group. With these thoughts in mind I propose this replacement for the initial section. I have thoughts on the scope and process as well, but this is enough for now. W3C Solid Community Group CharterThe aims of the Solid Community Group and of the Solid Project it is a part of, are in line with those of the Web itself: empowerment towards "an equitable, informed and interconnected society" [1]. Solid adds to existing Web standards to realise a space where individuals and communities can maintain their autonomy, control their data and privacy, and choose applications and services to fulfill their needs. The group supports these goals by
The group has three target audiences it aims to support - specification writers, application developers, organizations and individuals using or considering using Solid to meet specific real world needs. The group will foster discussion among these constituencies; including use cases and implementation feedback on both technical performance and social impact. Discussions will explore and describe the interoperability between different classes of products by using Web communication protocols, global identifiers, authentication and authorization mechanisms, data formats and shapes, notifications, and query interfaces. They will also explore social impact of these technologies and Solid-specific approaches to issues such as the delivery of social services, the storage of health and identity records, the monitoring of environmental damage, and similar real world issues that Solid can be applied to. |
|
Jeff, thank you for sharing your thoughts. I appreciate that you are emphasising important points which are good to clarify CG's goals, and how they overlap and differentiate from the Solid Project and the wider community as a whole. It is important to keep W3C Solid CG focused on incubation of specifications and implementations. Open standards development naturally includes in- and out-reach communication with various stakeholders. Please bear with me as I attempt to summarise a few relevant areas that are already part of CG's activities: On societal impact: the Solid Protocol has a dedicated Societal Impact Considerations section: https://solidproject.org/TR/protocol#societal-impact-review . It is a stub based on a W3C TAG draft. I've introduced this in 2021 so that we are mindful and to get some considerations acknowledged and documented. It ties into and expands on what's stated in Introduction with respect to using the Ethical Web Principles to orient ourselves - "every technical decision has ethical implications both for the end user (short-term) as well as society (long-term)." If need be, a dedicated Task Force could be set up to further investigate and develop these, and share their findings with the CG in the context of a particular technical report, however, it may be better for the wider Solid community to communicate the broader considerations through the Solid Project or via a Solid Team publication. On adoption and communication: solid/specification#402 places emphasis on challenges we need to take on so that the work is useful to implementers, developers, contributors to TRs (including Work Items), and general public. It is closely related to the Solid QA Initiative: https://solidproject.org/ED/qa (see also Test Suite Panel Charter as we aim to produce verifiable data (as opposed to resorting to perceptions). Developing good conformance models defining their classes of products and what constitutes interoperable are key, and they go a long way. While "server-client", "client-client", or "server-server" and so forth, may be generally useful concepts in some contexts, they're not sufficiently specific or meaningful going forward especially when multiple and varying specs with their own products which are attempting to be express interoperability. This is not hypothetical. In the past year or so, we've seen some of the Solid CG specs adopting this view (technically building on the monumental work of the W3C QA Initiative) and improving their conformance models, and ultimately helping us improving our understanding and development of the Solid ecosystem. The current scope covers the key areas with more precision and hints at a range of products that'll materialise. One place to continue this discussion/work is in issue solid/specification#480 . On developer engagement: please rest assured that specification editors/authors have been working hard and are very much engaged. Needless to say, they're also implementers themselves! Editors/authors do regularly seek implementation commitments, gather feedback and integrate, recommend improvements on implementations, answer questions in/around chats and GitHub issues/PRs. Furthermore, you'd pleased to know that there is a recurring topic in CG meetings on WIP implementation feedback for some time now, with fairly regular updates from implementers. I am confident that we'll find ways to improve gathering and reviewing of significant implementer and user feedback from various places. The Contribution Guide provides some details. The importance of significant use cases and user stories are still very much core to the CG. As you know, there are some UCR documents (and they can be improved) as well as dedicated repositories. Here is one particular meeting dedicated to reviewing our work around UCs and next steps: https://github.com/solid/specification/blob/main/meetings/2022-12-14.md - Note that it mentions Priority of Constituencies - where it comes up sporadically in CG workspaces - but your comments also reminded me to make sure to incorporate the design principles into the Charter. That said, I'm with you on continuing on these efforts. I just wanted to emphasise that the considerations that you are highlighting have been taken into account and integral to the CG work (from early on), and reflected in the Charter bar tasks that may be better fit for another grouping . If clarifications are needed we can adjust the language. |
|
I agree with Sarven that it'd be important to not overlap with the general initiatives of the Solid Project / Team here. I think developer outreach and community building fall under the purview of the Solid Project and/or the Solid team (as reflected in the recent scope discussions). This PR (which has been approved, pending merge) states:
We can update this description by adding details as to how we are "facilitating a strong open source community", which can include the activities in scope for the Solid Team, covering many of the activities you mention here around supporting application developers and community outreach. As to:
I believe some of those goals are already specified in the proposed charter, and I think they don't need to explicitly call out "client-client", "client-server", and so on, since that is already understood from "drafting and incubating proposed technical specifications for further standardization and prototyping and testing implementations" in combination with the scope.
These are all great points. As mentioned above, these are the discussions currently being had in the Solid Team (in the context of defining team scope) around how to improve developer onboarding and community outreach, among other tasks supporting individuals regardless of background to contribute to Solid. I do believe the points that Jeff is making are important and deserve a revisit in the Solid Team for the Project's mission and goals in the context of the Team's recent scope discussions. Let's take this up in one of the team meetings. |
I appreciate the work the CG has put in on social impact and implementer feedback and am not trying to say that he CG has done nothing in this arena. On the other hand, my perception is that the focus is always on the spec writers and not the implementers. For example, do you have a list of the implementers who have presented at the CG? Have you taken any steps to network implementers working on related verticals? Do you do any kind of follow-up or publish any information on implementers? In each of the last two CG meetings there were individuals from implementation projects who did not speak in the meeting. I corresponded with both of them and have looped one of them into a meeting with a similar project on another continent. I would like to see this kind of outreach formalized as part of the purpose of the CG. [EDIT] : I'd like to clarify that my comments above are not meant as a criticism of the CG - the CG has rightfully been focused on the WG charter and I have no issues with that. I'm speaking more to what could be done in the future. |
I am not categorically against that approach, but I'd like to point out my reasoning for wanting these functions in the CG. My perception is that there is a big gap between the specifications and the community using them and that both sides of the gap can benefit from a narrowing of the gap. My perception is that the group who consistently attend the CG is very small and that the only implementers who stick around are ones who are also spec writers. My perception is that there are many people whose names are listed as being members of the CG who could be motivated to participate in the CG if they perceived a role for themselves. |
I think that one of the most significant features of Solid interoperability is the client-client architecture and that it deserves emphasis. I think that if the WG charter is explicitly about server specifications and the CG charter does not mention client-client, that de-emphasizes a critical part of the architecture. |
Jeff, I won't challenge your perception. Again, on the contrary, what's on public record - the objective reality - is that specification authors and implementers have an open dialogue on a daily basis on publicly accessible GitHub repositories and Gitter/Matrix, among other places. Nor is it ever the intention that "the focus is always on the spec writers and not the implementers". What we are doing is not architecture astronomy. As mentioned in the Introduction, "the consensus on the technical designs are informed by common use cases, implementation experience, and use." You're welcome to challenge that or share your perceptions. Here is even a dedicated meeting for implementer feedback: https://github.com/solid/specification/blob/main/meetings/2021-10-21.md . We'll strive to do better. But to be clear, the group is not pretending to be physically and emotionally doing everything everywhere all at once.
You're to first to ask about this. Yes, not only a list but their descriptions can be obtained from the minutes. Implementers are not limited to the presentations at the CG or CG meeting either. That information is also available from chats, GitHub, e.g., issues, UC surveys, call for implementations, mailing list, and even conferences and research documents. If "a list" is deemed to be useful, I can only encourage you to write automated scripts to generate the data. That aside, we have taken several steps further than just compiling a list. For instance, the Solid QA aims "to give authors of technical reports and software implementers confidence that they can rely on the Solid ecosystem to deliver on the promise of interoperability based on open standards." Emphasis mine. Those are not just words or accidental. All of how we get there is detailed / WIP in https://solidproject.org/ED/qa where various stakeholders come together to meet our goals, and you'll get far knowledge than a "list of the implementers". So, Solid QA is another area to get involved in because that's where we work towards showing implementation reports and adoption based on data, as opposed to perceptions.
I think that question is a touch too vague in these circles. To re-emphasise, not everything is on the CG to take on, which includes "network implementers" above and beyond what the CG is already doing. The kind of networking you may be curious about may be better handled via the Solid Team. Two of the Solid Team meetings that I know of touch on this topic: https://github.com/solid/team/blob/main/meetings/2023-05-10.md
See my points on Solid QA, and the work that goes towards test reports and implementation reports. There are unofficial test reports about implementations, e.g., https://solidservers.org/ - FYI, it is unofficial because the consensus was that Solid QA will detail how to produce "official" publications. Moreover, some of the specification and test contributors have in fact went out and reached implementers on what they are doing correctly and what could be improved in their implementations. To my understanding, in addition to public communication, there is also private communication towards that end.
I applaud your efforts to reaching out. I will encourage anyone to follow in your footsteps. In general, outreach is already part of works that CGs do, and evidently you were able to accomplish outreach without any special formalisation. As you've undoubtedly noted, there is a whole Introductions topic in the meetings and it is also part of the meetings template. The groups makes sure to welcome new names. If they choose to not speak, they're still welcome to participate in the call. Likewise, people are not obligated to speak or present their work, and newcomers might prefer to have space to explore rather than being contacted directly immediately. There are nuances to all of this.
Sure, that is a possibility. As far as I can tell, it comes down to picking up tasks and getting things done, over handing out roles and hoping for the best. I've seen countless times folks sign their name up or want credit/privileges/authority but have fallen short on delivering. Yet, I've seen folks over the years making remarkable contributions day in day out without asking for special roles. There is data.
I believe what's intended with "client-client" in the context of Solid, is abundantly covered under the Scope. That's besides the notion of "client-client" not particularly well-defined or common out there, but please do share commonly accepted references that'd be meaningful for the Solid CG. If and when there is a question of whether a proposed work item fits under the Scope, the charter already explains ways to incorporate or reject. |
|
@csarven thank you for the pointers to the excellent existing work of the CG on engagement with implementers. I have no criticisms of existing work. What I am saying is that we are entering a new phase which calls for new layers of organization. For example, you write
That is fantastic that you and the CG have created all of that. Thanks and congratulations! It is exactly that list that would be generated by that data I am asking about. I am aware that I can gather such a list and have actually started. I believe that the gathering and dissemination of that data should not be left to me as an individual but should be a recognized function of the CG. I believe that there needs to be a focus on community engagement that makes data like this available to a wider audience. This has never been an aim of the CG so it is not faulting the CG to say it hasn't been done. But now that we're in a new phase, it needs to be done. This example also points to one of the reasons I believe that the community engagement function should live in the CG. Why should anyone have to go back and gather all of that data rather than it being a part of the process to create a registry of information as we go? And why shouldn't we have tracks and meetings aimed at the wider community? Yes, for sure you've already done some, but I am talking about a real effort for community engagement where dissemination and use of Solid is the focus rather than creation of Solid.
Again, I think this should be an institutional function, not left to an individual.
When I said "if they perceived a role for themselves" I didn't mean a named role, I meant perceived that they could learn and contribute. |
|
Given that we need at least a clear line between
Do we need to further distinguish Solid CG from
? I'm worried that we may end up with the same issues as with the panels (some thoughts in #324) Yesterday I had a short call with someone who is going to work on a project which aims at improving the Solid app development experience as well as the user onboarding experience. I'd like to share here something that Solid CG/Team/Project/Community/Ecosystem/... needs to address. I think there is a justified urge to make user onboarding as seamless as possible. At the same time, I think there is a thin line between making onboarding as smooth and as honest as possible and making it dumb and prone to long-term negative perceptions of Solid. For example:
I think this is a realistic scenario, where the temptation to oversimply user onboarding leads to a bunch of users who might feel burned by Solid and end up very hesitant to have anything to do with it again. IMO Solid CG (if that's who takes long-term stewardship over Solid) can address it by recommending and cautioning about the user onboarding process. Providing clear and multilingual information about pros and cons of using one's own domain vs. relying on domains offered by providers of various Solid services. This is only an example, the main need it exemplifies is long-term stewardship over Solid, user/developer experience, and their perception of Solid and trust in it. |
Co-authored-by: Wouter Termont <woutermont@gmail.com>
A common procedure is just to use CG membership (literally people who have pressed 'Join this Group' button on the W3.org site) for votes. |
|
To address concerns of potential conflicts between Solid CG and Solid WG scopes. The proposed Solid WG charter already states:
https://solid.github.io/solid-wg-charter/charter/#add-new-deliverables While Solid CG charter submitted in this PR states in out of scope section:
I think those two together set a clear boundary between CG and WG scopes. It also describes the pipeline where drafts get pre-processed in CG and can move into WG. I believe this is a common practice used in Credentials CG and possibly other ones. |
|
I was trying to look up the history of chair selection in Solid CG the public mailing list doesn't really answer it @csarven could you shortly write down how you became the Solid CG chair? |
There was a problem hiding this comment.
The charter looks good (approve). Great work by all the contributors!
One small consideration would be a rewording part of the scope section opening sentence from
"...enabling affordances for decentralised Web applications to create and use data across decentralised storages in a way that is secure and privacy respecting for individuals and communities."
to:
"...enabling decentralised Web applications to create, use, and store data securely across disparate domains in a way that respects privacy for individuals and communities."
|
Pavlik, there are threads discussing some of the chairing, starting with https://lists.w3.org/Archives/Public/public-solid/2018Oct/0004.html . The CG self-organised to appoint chairs. There wasn't a process above and beyond folks stepping up to the service and the existing chairs appointed or stepped down overtime. It followed W3C's recommendations for CGs: https://www.w3.org/community/about/tool/#choose-chair . I was appointed as co-chair in 2019 by Mitzi László, who was the chair at that time. There was no ceremony about it around that time. I just served the community on the ground level, keeping stuff running and advancing, and as expected of the chair role. I've gathered closest snapshots from the Internet Archive of the CG webpage indicating changes to chairs:
If anyone would like to investigate further to help improve the charter, we or they can request data from W3C. |
As per resolution in [2023-08-09 Solid CG meeting](https://github.com/solid/specification/blob/main/meetings/2023-08-09.md#mit-license-andor-w3c-cla-and-fsa) Co-authored-by: Wouter Termont <woutermont@gmail.com>
Co-authored-by: Wouter Termont <woutermont@gmail.com>
|
@dmitrizagidulin, to my question about vote, and your answer:
That's to register participation interest. That'll add the participants email address and communication will be sent through it. I've noticed the meeting invitation, there's the calendar link, etc. But the votes. Voting. I'm assuming it's during a meeting, with Zakim, the minutes bot, tracking presences, |
Co-authored-by: Wouter Termont <woutermont@gmail.com>
As per agreement in https://github.com/solid/specification/blob/main/meetings/2023-09-06.md#solid-cg-charter Co-authored-by: Wouter Termont <woutermont@gmail.com>
|
Merging as per 2023-09-06 CG meeting decision. Thank you to everyone who contributed their time, knowledge, and passion to improve the charter through constructive discussions and collaboration. We made it so! :) |
(W3C Solid CG Chair hat on)
I believe it would serve the W3C Solid CG well to have a charter and with a revised simple and clear process.
In this PR, I would like us, the CG members, to consider adopting a charter that can work better going forward. The charter aims to:
It is intended to supersede the process outlined in solid/process (README). The current process in general is:
This charter is written in accordance with the W3C Process and aims to remain compatible as much as possible. In addition to following a typical W3C charter outline, the document includes chair elections and work item proposals. Some of this information could be moved to other documents or repositories but it is presented to you as a whole to kick things off. For example, the Solid Technical Reports Contributing Guide is a thing on its own to have a shared understanding of what's in practice as well as providing detailed information on how individuals can contribute to the CG.
On chairs: the Solid CG would certainly benefit from more chairs representing a wider and more diverse set of voices and perspectives in the community, as well as giving the people who have a demonstrated track record of participation and work in the CG the opportunity to continue their service in a more effective and efficient way, with the proper structures for their work to be meaningful and impactful. For these reasons, when this charter is effective, I intend to arrange an election and open up the option to anyone in the Solid CG. The election process is based on what other CGs have done, and has been working well.
On work items: the Solid CG, within the framework of a W3C CG, generally have a "low bar" to getting stuff done based on open participation and volunteerism. Hence, the process is only intended to help the CG ensure that proposed works are within the scope of the CG, its placement among other work items is understood by group members, and ownership and commitments are stated up front.
This charter is meant to serve as a starting point for the CG to collaborate on the definition and refinement of the processes. Contributions in the form of feedback and requests for clarification (among others) are welcomed and encouraged.
Let's make it so! :)