Proposals for improving WECG meetings #145
Comments
|
I haven't been participating in the meetings, but I've been reading the meeting notes and either participating or lurking in all channels of the community at large for a long time. The reason you can't come to consensus on various things isn't because of some lack of organization; It's because of serious fundamental disagreement on the vision for the platform and what is actually important. For all intents and purposes, whichever way Google decides to deviate from any proposed standard will presently become the "de-facto standard", and so the times that Google has expressed "we may do things our own way to protect our interests" has effectively meant "we are not genuinely interested in standardization efforts". This "meeting about meetings", so to speak, is worthless procedural busywork. Its motivation is a presumptive misappropriation of the reasons for failure to stay "on track" (whatever that even means). It's pointless to even pretend that there is any purpose in consensus-building when one party who does things purely for its own benefit holds all of the cards. For example: If there is a "champion" required per proposal, then there should be a "champion" required who bears the burden of trying to justify e.g., arbitrarily-ephemeral service workers despite widespread community pushback. But instead, this proposal is taken as a mere "fact of life", because the only browser vendor who really has any power to set these sorts of standards has force-pushed it into existence through community disapproval for its own purposes. This is not how you solve problems as a group. It's a bad-faith effort on Google's part. This is the type of thing that leads to "sidetracked" airing of grievances in a meeting. It's not caused by merely "lack of organization". When you try to solve something you perceive to be a problem, you have to really genuinely ask yourself, "Why is this problem occurring in the first place?". The answers are all right here, and have been obvious all along. The members of this community feel powerless and unheard because, well... they are. |
|
What are the biggest issues facing extension developers today? What is the purpose of this group?
The charter specifies a number of design principles this group is meant to uphold. Various parts of Manifest V3 violate principles such as "user-centered", "compatibility", "performance" and "maintainability". "Security" and "privacy" principles, currently concerned with malicious extensions only, are violated as well when you consider that MV3 makes it harder to create and maintain effective security and privacy extensions. Will these proposals help the group be more effective at addressing this dissonance? |
|
I wanted to make sure I replied here, since I appreciate you asking for feedback. Agenda preparation
This sounds great! I can't really see any reason not to do this as it seems like a win for everyone.
Similarly, I think this worked well in the last meeting and I like the idea of continuing it. Keeping meetings productiveI really like the idea of setting goals for each agenda item - we should make to explicitly list those in the document. That way the chair can re-focus the discussion on the questions that need to be answered/the browser vendors we need input from. While a topic that over-runs significantly may need to be cut short and continued in the next meeting/offline, I think setting goals is definitely a better approach than having a hard time cut-off after which discussion is ended. It means the person who added the item to the agenda will get what they wanted from the discussion while still allowing us to keep things fairly focused. Driving issues to completionI love the champions idea! I think if we could have two or three ongoing projects with champions for each, we could see more activity in the Matrix and GitHub and that would be super exciting. On top of that we could also put emphasis on documenting what people agree to do offline/adding agenda items to the next meeting in the current one if someone says they will follow-up with something. Other notesI apologise for bringing things back to MV3 but I think something to come back to as a closing note is that half of these problems are general organisational issues (solvable with what we've mentioned above), and half are because developers don't currently have a great place for MV3 questions. If we can solve that problem (a less frequent MV3 Q+A call perhaps) I think the noise will go down in regular meetings and some of the teething issues we're experiencing will be overcome. |
I think this is a good idea, MV3 is a big change and we could spend all of our meetings discuss pressing issues, but some of those are specific to, or only pressing for Chrome (because of Google's MV3 timeline), so we should be more intentional with our agendas to have a space to progress on other issues as well. I'm going to think more about a concrete proposal here, and discuss it in our next meeting. |
In our meeting (minutes) I shared some thoughts on possible changes to our meeting structure. This issue expands on those ideas in order to give group members more space to consider and discuss the changes I proposed.
Background
Since the WECG started holding public meetings in June 2021, we have used roughly the same structure for all of our meetings. Meetings are divided into two main blocks: discussing agenda topics and discussing items in the queue.
Before the meeting the presiding Chair creates an agenda in our shared Google Doc to help guide discussions. The structure of the agenda has organically evolved, but at the moment we typically include topics that 8000 weren't addressed in the previous meeting, new issues, and a set of topics selected by the Chair. The Chair's selection is subjective, but is typically motivated by relevance to recent discussions, extension author concerns, browser vendor interest, time sensitivity, and the group's charter.
The topic queue provides meeting attendees with an opportunity to raise other topics they would like to discuss.
Meetings typically proceed as follows: opening remarks, topics we didn't cover in the previous meeting, new issues, chair-selected topics, queued items, closing remarks. Topics are generally given however much time they take, with Chairs or Editors occasionally encouraging attendees to be mindful of time.
Motivation
The WebExtensions Community Group's goals, scope of work, and deliverables are explicitly specified in our charter. This document also outlines the responsibilities and expectations of the group's Chairs and the process by which we conduct our work.
1. Agenda preparation
Our current process does not give group members an opportunity to prepare for meetings or to influence the agenda.
Proposal A: Create the agenda early
The agenda should be complete at least two days before the meeting.
This change will provide members across the globe with an opportunity to review the agenda and prepare for the meeting.
Proposal B: Prepare agendas in GH issues
Rather than prepare the agenda in a Google Doc, agenda preparation should take place in GitHub issues.
This will make the next agenda more easily discoverable, encourage member participation in the group's GitHub issues, and make it possible for members to discuss the agenda asynchronously before the meeting.
Furthermore, the agenda issue for the next meeting should be created at least one week, preferably two weeks before the meeting. This time frame will enable richer discussion and broader participation among members.
2. Keeping meetings productive
Discussions during meetings can (and do) go off topic and repeat previously raised points. While we should seek to enable open discussions, we must also be conscious of how we use our limited synchronous meeting time.
Proposal A: Timeboxing topics
During the agenda creation process, Chairs should assign each topic a maximum amount of allotted time. Members are also encouraged to discuss time expectations when proposing topics. Final allotment should be adjusted based on member feedback and competing agenda times.
If time runs out during a meeting, Chairs should encourage participants to wrap up discussion in order to address the next topic in the agenda. Members are encouraged to continue the discussion asynchronously on the appropriate GitHub issue. If the topic bears further synchronous discussion, members should work with Chairs to add it to the next meeting agenda.
Proposal B: Topic goals
All agenda items should have a well defined goal.
This practice would help focus our attention on driving towards that goal in order to resolve the issue(s) being discussed. Additionally, a clear goal would not prevent us from continuing to hold open discussions during meetings; collaboratively exploring a problem or discussing concerns can be a highly effective use of our time.
3. Driving issues to completion
It can be a challenge to make material progress on projects in an open, loose, consensus driven group such as this. In my personal experience, one of the common issues I've seen is that it can be difficult or impossible to make meaningful progress when a project doesn't have an engaged "directly responsible individual."
The two main ways I feel this is manifesting in WECG efforts are:
Lack of progress on specifying the common WebExtension API surface across browsers
Many open issues without criteria to resolve them
Champions
Previously "project stewards"
This is more of an area of thought than a proposal: would the concept of a "champion" be useful?
I'm thinking a champion would be a member who is recognized as the primary person attempting to drive a given concern to completion. A "concern" could refer to a specific GitHub issue, general problem space, a specific proposal, a section of the WebExtensions specification, etc. "Resolution" may mean any form of completion, whether that be organizing discussions, working through several different proposals, landing a spec change, deciding to close out the concern.
This is inspired in part by TC39's concept of champions.
The text was updated successfully, but these errors were encountered: