Self-Review: Chairing
More details about this document
- Identifier
- https://csarven.ca/self-review-chairing
- Modified
- Published
- Language
- English
- License
- CC BY 4.0
- Notifications Inbox
- https://csarven.ca/archives/self-review-chairing/inbox/
- Document Type
- Article
- Document Status
- Published
- Policy
-
- Rule
- Offer
- Unique Identifier
- https://csarven.ca/self-review-chairing#document-policy-offer
- Target
- https://csarven.ca/self-review-chairing
- Permission
-
- Assigner
- Sarven Capadisli
- Action
, so goes the saying. But, it is a privilege to have the opportunity to show up, so we ought to use it for common good.DecisionsStandards are made by those who show up.
I have had the privilege of working on open web standards since 2006 with individuals and organisations from diverse backgrounds, all sharing a common passion for making the web a better place. In this article I reflect on my experience serving as the chair of a group, and mention some technical contributions as an editor, author, and implementer. The most current list of my technical and community contributions and related presentations and talks is available.
My contributions to open standards development began with HTML5 and microformats (2006); worked on laconi.ca/identi.ca/StatusNet platform (2008) — a global open source project designed to empower individuals, organisations, and communities to manage their social activities in a decentralised and federated architecture — leading up to OStatus (2010), which then paved the way for me to making technical and chairing contributions to W3C Interest Groups (CG), Community Groups (CG), and Working Groups (WG). Here is a slice of that:
- WebID Community Group (2011–present)
- WebID 1.0 - Web Identity and Discovery, WebID-TLS - WebID Authentication over TLS, The Cert Ontology
- Government Linked Data Working Group (2011–2014)
- The RDF Data Cube Vocabulary, Best Practices for Publishing Linked Data
- Social Web Working Group (2014–2018)
- Activity Streams 2.0, Activity Vocabulary, ActivityPub, Linked Data Notifications
- Web Annotation Working Group (2014–2018)
- Web Annotation Data Model, Web Annotation Vocabulary, Web Annotation Protocol, Embedding Web Annotations in HTML
- Solid Community Group (2018–present)
- Solid Protocol, Web Access Control, Solid Notifications Protocol, Solid QA, and almost everywhere in Solid Technical Reports
I have been participating in several dozen W3C Groups on various topics with varying levels of engagement as an individual representing a W3C Member, Advisory Committee representative, Invited Expert, independent contributor, and chair. I value the works of the Positive Work Environment Community Group (PWE) and the W3C Process Community Group. I have been incorporating their recent developments in processes and guidelines to day to day work, and contribute to them where I can.
Following the control yourself
and do it yourself
schools of thought, I've implemented products that adhere to specifications. I have been building what I needed, and use it (still). Perhaps it all started on my personal website (2004). In most recent years, I have been focusing on exemplifying standards through the dokieli application, a socially-aware clientside editor for decentralised article publishing, annotations and social interactions — see okieli dokieli on how this work is intertwined with an ocean of open web standards, or if you are limited on time, think of the first WorldWideWeb browser-editor or Amaya using latest standards in the Open Web Platform.
Diving into Solid
Solid adds to existing Web standards to realise a space where individuals can maintain their autonomy, control their data and privacy, and choose applications and services to fulfil their needs.
We are tasked to fix the Web, society, or something? Right… easy peasy.
In 2015, I had the opportunity to dive into the Solid Project commenced at MIT as a visiting Ph.D. student, working with friends and colleagues involved in and around everything personal and social web. I am grateful to have met individuals who guided me to be more mindful of concerns of individuals and groups, implications of what we are attempting to build, and to fundamentally remain ethically grounded while at it. I truly find this to be the most challenging aspect of our work.
In 2019, sometime after self-publishing my dissertation, Linked Research on the Decentralised Web — making the case for a Solid-like approach for research communication — on my Solid server with dokieli, I focused back on the development of technical reports and chairing the W3C Solid CG.
I have been actively contributing to Solid's evolution, witnessing its growth from research and development — remembering our Friday hackdays with vegan pizza; contributing to server development with the needs of users with applications, and conformance to specifications; developing a browser-based authoring and annotation application (dokieli); initialising and cultivating a community; evangelising and lecturing the underlying concepts through talks at conferences, visiting research labs, and organising workshops; taking part in the standardisation process; and so forth.
Chairing the Group
In late 2019, I took on the chair role in the Solid CG. The role needed a commitment, and I had experience in W3C Groups. I was familiar with the W3C process and the broader community, and have learned from previous individuals in chairing and similar roles. I believed I would be fair and effective, so I wanted to apply my knowledge and experience to help the project move forward. I also learned a lot by doing.
I embraced a guiding principle: chairing is a service to the group and the open standards community by adhering to The Modern Paradigm for Standards. I took the role seriously, set my performance criteria, left any affiliations I had at the door, and remained open to adapting to the community's needs.
Some context: during most of my time as chair, the CG followed the Solid Process. It had its editors team, of which I have been a member, appointed by the director (TimBL) of the Solid Project. This team is not to be conflated with the editors of all specifications in the CG. In hindsight, the Solid Process had its merits in certain areas and partly served its purpose, however it generally ended up complicating our ability to getting things done. I will come back to this later when I talk about the CG charter. At various times I had to balance different forces. I had to find creative ways to evaluate and prioritise the roadmap of the movement led by the Solid director — whom I learned a lot from — with the general and specific needs of the CG. I also encountered direct and indirect pressure from my workplace (at the time) that I had to resist — expectations conflicting with my roles in the CG and open standards development. So, all of that put together, it was unnecessarily complicated and stressful, to say at the very least.
Facing technical and social challenges prompted me to grow as a person and encouraged me to review my own principles and values. Depending on participation, on a good day we (CG) were aligned and moved as a group, and on a bad day, we clashed, lost time, and energy. I lost trust and gained trust in individuals, myself, and in the project or certain projects, and sometimes all on the same day. I have lost contact with some colleagues, improved existing relationships, made new allies, and helped others connect. Through chairing and other technical involvement, I developed a better understanding into how we frequently get caught up in protecting our artifacts and attaching ourselves to objects (be it ideas, plans, implementations, issues, or pull requests), which may be a way of protecting the extensions of ourselves. From my perspective, it took a lot of mindfulness and acting in good faith to move together.
Chairing required me to leave my own sense of logic at the door, set aside own preferences, actively work towards compromises. I tried my best to facilitate consensus, and not compromise on fundamental expectations of the role. I still shared own findings and proposals when I thought that they would be beneficial to the group, but I was also prepared to let go of things and have the group organically evolve and make decisions. I think any seasoned chair would agree that this is all easier said, and takes work and a lot of patience and emotional bandwidth to navigate through things.
Looking back, I am cognisant that I have made both sound and flawed decisions over the years. And a bunch all over the place depending who we ask.
Communicating in text is challenging, audio is an improvement, video is even better, but nothing ever compares to face to face, or working things out on a whiteboard. This has been indisputable in every group I have been part of. I enjoyed making light jokes in meetings and chats when the group felt receptive and relaxed. It's also great to see people sharing personal anecdotes from time to time.
Say Process Again!
Initially, the governance and processes towards standardisation in the group started out with one foot on the Solid Process and the other on W3C processes. The CG generally practised rough consensus
decision-making, and fortunately hardly ever needed to decide on substantive technical issues by voting as we were able to reach consensus and compromise most of the time.
Over time it became apparent that the Solid Process fell short and did not reflect reality. The group found it technically complicated and convoluted, and newcomers could not make sense of it. The process depended on certain roles (such as the "editors team") that have been inadequate and inactive for a number of years. A process was only useful if it served our needs and participants abided to it. We needed to improve things.
The Solid CG charter, which I proposed in 2023, bears a resemblance to a WG charter, aligned with the practices and process of the W3C community, while still intended to be under the umbrella of the Solid Project. The CG charter was to supersede the Solid Process with respect to specification development, aimed to simplify and codify things; be representative of current working practice and goals; maintain openness and transparency; be approachable or informative to anyone; and to communicate group's ongoing endeavours. The charter was generally well received in the CG. We worked on it for about two months, incorporating great feedback in all areas, and finally reached consensus on its adoption. It was also interesting to note certain individuals and groups who are otherwise vocal or represented did not contribute to the discussion or improvement of the charter.
As per W3C CG process, typically the existing chairs appoint co-chairs, and life goes on as with an oligarchy. That did not seem adequate to me, and I chose not to exercise my supposed superpowers (as the sole chair) as to who I wanted to add as a co-chair. It may seem strange or concerning to some to know that I actually had to argue for a participatory democratic process in the CG charter to ensure an inclusive and representative approach by using the ranked-choice voting method for chair selection. Despite some folks not understanding the Solid Process (and its inadequacy, as evidenced) or W3C processes, there were complaints about why I did not assign people that the director suggested. Some even complained that voting is far too easily gamed. The response to that was to update the charter to be even more aligned with the W3C Process and doing something similar to Advisory Board and Technical Architecture Group Elections. Besides, other experienced and engaged CGs had already embraced a similar approach, demonstrating that my proposal was in alignment with established practices.
When we (CG) picked up the draft Solid WG proposal, it required a rewrite due to essential corrections and improvements. The majority of these revisions were informed by the lessons learnt from common formal objections, ensuring that the charter accurately reflected the activities of the Solid CG and the broader community. Evidently, these improvements helped pre-empt typical formal objections at the outset and reduced the need for multiple rounds of discussions among the CG, W3C Team, and Members. There are however other objections and change requests that are currently being addressed by the CG. Interestingly, a key W3C Team Decision ended being the primary source of objections or request for changes to the WG charter.
I believe this journey reflects my leadership, adaptability, integrity, and commitment to improving the CG and work towards the WG. I dedicated considerable effort, in collaboration with the community, to enhance inclusivity and transparency. I am offering these experiences as a valuable guidance for future contributors and chairs volunteering to take on this multidisciplinary challenge in order to achieve more democratic and diverse outcomes.
Charters and Contribution Guidelines
I have noticed that the group could benefit from further support and guidance on open standards development, for instance on how the group conducted itself in a W3C space, as well as developing experience towards publishing technical reports and test suites. This presented a chance for me to further learn as well. I figured that the CG could better take advantage of the W3C material by having it operate a bit more like a WG and follow the W3C Process where useful or applicable. This had a couple of benefits: to help the group take advantage of existing W3C processes, findings, recommendations, infrastructure, and so forth; to help the group to situate and familiarise themselves with W3C know-hows during the incubation phase (so that if and when work items are transitioned to a WG, participants can be well-informed with the rules and expectations as opposed to diving cold); and proactively mitigating internal and potential formal objections down the road in the Recommendation track. To that end, I embraced the collective wisdom and advice of W3C (all the way to open issues and ongoing discussions), and plugged-in anything that I could get my hands on to improve group's processes and development. Some folks were on board with these ideas while others needed more time and convincing to adjust themselves, and some others had their own agenda.
I had previously proposed topical charters in the group for Test Suite and Notifications. These served well to keep things in scope and to meet some goals. Their output has been Solid QA (and ongoing work on test suites and tests), Solid Notifications Protocol, as well as related specifications (as listed in the notification channel type registry).
I have put in a lot of work into developing the CG Contributing Guide to capture a shared understanding of what's in practice, providing detailed information on how individuals can contribute to the CG, as well as guidance on external communication.
I have also developed the CG Meeting Guidelines, detailing expectations and descriptions of various roles in meetings. As for the meetings themselves, the CG uses a collaborative editor where we have an assigned scribe. The CG has adopted the practise where meeting participants have been improving the transcription with corrections, missing information or links. I have created a meeting template that the CG has been using for some time now. I must say that I was initially sceptical of some participants preference (at the time) to using a collaborative editor for minute taking instead of W3C's infrastructure, i.e., IRC with helper bots. I have noticed that with a culture of trust and a meeting template, it has proven to be useful. We have even developed Solid Ecosystem Monitor — an application that presents our meeting data with visualisations.
Eating Our Own Cooking
Building and using what we need helps to advance things significantly.
I wanted the CG to aim high: build up adequate implementation experience in order to work effectively; demonstrate the maturity of the specifications; and establish a culture as if the works were progressing toward the W3C Recommendation track, with the hope that it happens in due course. Towards that end, we have worked on use cases and surveys; call for implementations; the QA process and tests; supporting and coordinating with implementers (in chats, issues, and PRs); and actually using what we build, among other things. While not everything worked great, sufficiently, or entirely adequately, these endeavours contributed to the overall objective, allowing the group to develop a more robust understanding of processes and coordination.
I employ a Solid server to host this personal website (csarven.ca). What better way to publish human- and machine-readable of one's own information, including personal identity, profile description, articles, to social activities; having applications make use of that data; break things; and find ways to improve implementations and specifications?
Over the past years, I have been developing and showcasing dokieli to energise the group with a publicly accessible implementation as well as to demonstrate various use cases, proof of concepts for new specification features, and providing implementation feedback to specifications. dokieli has helped towards the QA work by showcasing how specifications, test coverage, and implementation reports are linked, making it relatively easy for specification editors, authors, and implementers to understand how specifications can be improved by better observing what their documents expressed and where improvements are needed.
I have also tried to encourage voluntarism by first being an example myself, requesting experts or doers to take initiative, especially when suggesting an approach or particular direction. I found it immensely important to show genuine appreciation and celebrate all forms of contributions, from recording or following up on an issue, creating important PRs which improve specifications, to improving the text of meeting minutes.
Work Items
It would take a whole another article to adequately cover the progress and evolution of the work before and during the CG.
Generally I referred to the Architecture of the World Wide Web, Volume One for guidance to ensure that the work items are compatible in scope of the group.
At times there was apathy in the group and so it wasn't particularly easy to claim that we've reached consensus. I tried to not rush on the proposals until there was some signal in favour or against them in reviews, chats, or meetings. It was a challenge for me to keep a balance between upholding our time commitments and allowing sufficient time for feedback and improvements.
That said, we have managed to move things forward — although sometimes painfully slow — to a point where they were mature enough to be transitioned from the incubation space to a standards track (as part of the WG charter proposal).
While the group has a roadmap, project board, meetings, issues, pull requests, and so forth, it all came down to who showed up, when, and what they could do. After all, most development is carried out by volunteers (some would, perhaps derogatorily, refer to them as "hobbyists"), whose availability, motivation, and funding varies. The fact that this project has been mostly propelled by volunteers goes to show that there are more effective, humane and cooperative models of development that go beyond the narrow-minded transactional model that is prevalent in tech culture.
Inclusivity and Conduct
Technical work aside, a community lacks substance if it isn't inclusive and ensures a safe environment. Even though W3C had considerable efforts in this area that the Solid community and the CG has put to use, cultivating a healthy community and abiding to acceptable behaviour doesn't happen magically.
I contribute to the development of the Solid Community Code of Conduct (CoC) — which extends the Positive Work Environment at W3C: Code of Ethics and Professional Conduct. As Solid CG chair, I had the responsibility to ensure that participants abide by the terms and spirit of the Solid and W3C CoCs. I also served as a member of the Solid CoC committee, and took part in processing of reports, mediating conflicts, and implementing necessary disciplinary actions.
I want to reflect a bit more on this important topic: My experiences as a CoC committee member were filled with challenges. It involved addressing unacceptable behaviour, and not all reports of violations were (or can be) resolved to everyone's satisfaction. Regrettably, I have seen friends and colleagues leaving the community because of some individuals with unacceptable or counter-productive behaviours, some of which occurred even before the establishment of the Solid CoC. Managing the tone of discourse is also a delicate task, so as not to be overzealous or block fluid communication. I have figured that while it took me considerable effort to try to transform unconstructive behaviours of some individuals into constructive behaviours, e.g., by inviting to take on a role or picking up a task of their choice, it generally led to two outcomes: they changed their ways to contribute or they stop being unconstructive (at least in the short-term). That said, I acknowledge that it is an ongoing effort to work together and make the community a place that is a safe and inclusive space for all. I am aware of the need to improve myself and contributions in this area. Including for example taking care of my own mental and emotional well-being when the situation arises.
So goes the W3C operating principle for effective participation is to allow access across disabilities, across country borders, and across time. To that end, I tried to set reminders to participants in meetings, chats, and elsewhere. I felt that helping people regardless of their accessibility needs or technical expertise kept me grounded and go together. It certainly took additional time from my end — which was part of the job, as far as I was concerned — but I understood that it meant the world to some people. That in and itself made the work feel worthwhile.
I have also been part of the wider Solid Diversity, Equity, and Inclusivity Team to help increase outreach of Solid’s work into communities with underrepresented groups. The group was mostly active in 2021 but then it stalled. I am aware that some individuals still carry on, so I'm cheering for them. From the CG end of things, I have made efforts to incorporate individuals from a diversity of backgrounds with interest to making technical contributions to take on the role of an editor, author, or implementer. I only tried to amplify their voice and make myself available to them when they needed my assistance. When motivated individuals have the opportunity to take ownership or lead in their work, they tend to do great.
Constructive Conflict Resolution
Our tone and the way we conduct ourselves impacts others and there are consequences to our actions. I have had my own share of knee-jerk reactions, and so I also had to self-reflect. Showing appreciation of others time and considerations, and being empathic, went a long way. It helped me to calibrate myself and find ways to understand and compromise when disagreements arise.
While minimising or avoiding conflicts may be generally better, I do see conflicts as opportunities that need to be converted into constructive outcomes. Based on what I have seen, coming up with proposals to resolve issues to be both quite self-rewarding and useful to the community, especially when it showed our shared needs, finding reasonable negotiations and compromises that we can make, and setting things in motion. For example, the work towards Solid QA partly came out of a resolution to a strong social and technical conflict among some participants in the group. Similarly, the CG charter was due to CG's need to be more effective, and ever more democratic.
I am constantly on the lookout for resources and materials to improve my skills, including running more efficient meetings. I have found the materials provided by the PWE CG to be quite valuable. I make modest contributions to the PWE, stay updated on their progress, and integrate any relevant changes or advancements into the Solid CG.
I have actively preserved CG's assets and maintained group consensus and consent. Including in situations in which I had to handle misconducts of some participants not adhering to group process and taking actions without group's consent. It has been my observation that when some folks actively undermine the whole group in order to fulfil their private agenda, they had lost the narrative of open standards development. The group handled such cases by allowing individuals to save face in the short-term, and by recognising the need for disciplinary policies and procedures. These policies involve training participants in the community's values and culture to maintain a healthy and constructive workspace in the long-term.
It goes without saying that I was challenged in managing conflicts — a part of me wanted to be firm on rules and expectations, but I almost always took things lighter, and tried to find constructive ways out of a situation. In my limited experience, understanding our differences and commonalities, approaching situations with empathy, and de-escalating are key factors in addressing various matters.
Coordination
I have had the privilege of coordinating with the W3C Team and the community. I think fundamentally I learned about inclusivity and teamwork, and that we need to work at it instead of taking it as something for granted. I did my share bit to align with W3C efforts and I had nothing but welcoming and supporting faces. There were always some random technical matters that people (and myself included) didn't always agree on but almost always found a way to have arrive at a mutual understanding.
During the CG and WG charter development, I took the opportunity to coordinate with W3C Team to have stuff running properly for the group. It involved anything from licensing matters with W3C legal, to transitioning CG's work items to the proposed Solid WG as its deliverables, to coordinating with the staff to run the CG chair election. The cherry on top of all is that, I have announced that I will be stepping down as the chair and will help the group with the transfer.
I have organised joint meetings with other W3C Groups, such as the Credentials Community Group, Web Platform Incubator Community Group, Autonomous Agents on the Web Community Group, and the Social Web Community Group. These meetings have been instrumental in fostering collaboration and understanding, building bridges, and aligning efforts. There were visible improvements and adoptions of related works in Solid work items, as well as their incorporation into the projects of individuals and organisations.
I have also led a mutual understanding between the Solid and WebID CGs in a way that was ultimately beneficial to everyone by proposing that the Solid WG charter adopts the WebID 1.0 specification as a deliverable. For Solid specifications, work on the WebID specification needed to be finalised. As there was plethora of publishing and implementation experience, as well as use of WebIDs in the wild, it made sense to graduate this work from the CG to a WG under a standards track. This proposal received unanimous approval from the actively involved participants, a relatively rare occurrence in such processes.
Make It So!
It has been my honour to serve as the CG chair. True effectiveness is achieved when we adhere to common principles and values in the standards development process, while remembering that there are humans behind the technical work we are doing. Social implications are the basis and the reason why all the technical work is happening, and it's very easy to lose sight of that in the day-to-day. Social all the way down.