I’m breaking this out into a separate topic for better visibility, and to avoid sidetracking the change proposal topic itself.
For what it’s worth, I think this captures what I think too, and what I remember from when we set this up initially.
I expect:
Change owners should make an effort to identify impacted teams, including edition Working Groups, and ideally include them in the proposal where it makes sense.
Fedora contributors should follow at least devel-announce (or “Watch First Post” in Change Proposals), and get involved if there’s something which comes as a surprise. (Not, probably, in a malicious way — it’s just a hard problem.) I know there’s a lot to keep up with, so maybe for key teams like the Workstation WG, have someone with “watch the Change Proposals, report back” as a responsibility every cycle.
There’s probably also some FESCo responsibility, as a safety check, to make sure that nothing like this is missed or unresolved before approving. (And that check/catch is what basically did happen here, I think — right?)
That way, we get the important conversations happening before we get into situations like “FESCo has approved this but the main impacted edition is unsure still.”
I think that, in this case, the change isn’t stabilised and doesn’t have engagement from all the stakeholders, so the fact that FESCo is voting on it causes some confusion.
Having a requirement that the working groups of affected editions should have given input on change proposals before they are put to a vote would make sense to me.
As part of this I wonder about the time line for change proposal votes. Currently there is 1 week for discussion, then voting starts straight away. That’s not enough time for a working group to see a change, discuss it, and respond with feedback.
(In this case, individual members of the working group did see the proposal and did comment, but our collective view about what to do about it only came later.)
I think that, in this case, the change isn’t stabilised and doesn’t have engagement from all the stakeholders, so the fact that FESCo is voting on it causes some confusion.
Yeah. ;(
Having a requirement that the working groups of affected editions should have given input on change proposals before they are put to a vote would make sense to me.
We used to require a represenative from each working group that came to
fesco meetings and followed activity to communicate back to the working
groups. That was pretty heavy weight tho, and I think it just slowly
disappeared over time.
As part of this I wonder about the time line for change proposal votes. Currently there is 1 week for discussion, then voting starts straight away. That’s not enough time for a working group to see a change, discuss it, and respond with feedback.
(In this case, individual members of the working group did see the proposal and did comment, but our collective view about what to do about it only came later.)
yeah. I don’t know that we want to make things a lot longer for the
usual case. Perhaps we could have working group members ask fesco to
defer something in cases where the impact is still being discussed.
I don’t think this is practical. Part of the reason we do the announce posts on devel-announce@ and on Discourse is so all the relevant stakeholders have the opportunity to participate in the discussion. I expect everyone, especially working groups to participate in those discussions.
In this particular case, the Workstation WG was paralyzed by disagreement by a non-member of the WG that some members of the WG leaned heavily on. This was complicated by the fact that the individual working on the Change is based in a location that is very difficult to align to the WG members for a meeting to discuss with them.
I do not think it would be reasonable to expect the WG to be able to offer an opinion of any kind in this scenario, but I also think that this is a sufficiently rare case.
The voting is supposed to start after the discussion has ended, or at least wound down. If there is active discussion and the proposal is being updated, voting doesn’t make much sense. I don’t remember if this is specified formally anywhere, but it is standard practice to wait. Either the Change Wrangler would delay the opening of the ticket or somebody from FESCo would ask for more time if there still was discussion or unanswered questions.
In this particular case, it seemed that the discussion was mostly over. People raised the question of compatibility with gnome, and the proposal was amended to include a plan for a compat layer to be provided.
If the WG has doubts and needs more time to discuss, it should be enough to say that in the ticket. We certainly can’t wait indefinitely, but there’s still time before F40, so we could wait a bit. @catanzaro made such a comment last week, and this resulted in quite a bit of discussion. The issue is tagged with meeting so there’ll be a chance to re-evaluate. Overall, I’m not sure if there’s any real problem with the process.
I don’t think this is practical. Part of the reason we do the announce posts on devel-announce@ and on Discourse is so all the relevant stakeholders have the opportunity to participate in the discussion. I expect everyone, especially working groups to participate in those discussions.
Well, sure, I don’t expect it to often be the case that a working group
wants fesco to wait. I don’t think there needs to be some heavy thing
here, just “hey, could you wait voting on this as the working group is
still discussing it”. Much like we do now for “There’s still discussion
about the change, lets wait for that to finish”.
In this particular case, the Workstation WG was paralyzed by disagreement by a non-member of the WG that some members of the WG leaned heavily on. This was complicated by the fact that the individual working on the Change is based in a location that is very difficult to align to the WG members for a meeting to discuss with them.
I do not think it would be reasonable to expect the WG to be able to offer an opinion of any kind in this scenario, but I also think that this is a sufficiently rare case.
I think that we’d likely need to formalise the process on the working group side if we want to consistently check over change proposals in a timely fashion.
It’s maybe worth noting that in some cases it takes a little while for our working group to get to grips with an issue. We generally just talk once a week at our meetings, each of which has a prepared agenda. Sometimes we might dispatch someone to do research or talk to the relevant individuals, and so on.
Maybe the problem isn’t huge, and maybe it’s just a matter of clarification. The main thing for me is that it feels awkward for a working group to be discussing a change while at the same time FESCo is voting on it. I feel like that has happened a few times in recent years, though my brain is failing to recall all the details…
There are also possibly a few other aspects of the change proposal process could be clearer or more explicit:
I don’t see it stated at what point the owner should mark their proposal ReadyForWrangler (ie. the plan should have stabilised and should have been discussed with the relevant stakeholders).
I also wonder if there should be some accounting for the fact that changes will sometimes require changes in upstream components, and that those changes should be agreed with the relevant projects. Maybe the template page could even list the affected upstream packages and have space for a link to the relevant upstream issue/merge request/pull request, for example.
This really sounds like the not enough communication between the WG and FESCo. The solution in my mind is simple though: add a comment in the FESCo ticket (preferably) or in the other discussion channels that there’s discussion going in another place.
ReadyForWrangler is when the proposal becomes officially public and open for discussion by all other contributors other than the Change Owners. The Change Owners may hold some early discussions with other stakeholders before that point, if they wish, but generally most of the discussion happens after.
Sometimes we have a Change Proposal that is a slam dunk and there is no doubt that it’ll be implemented. But most Changes are “aspirational”. When the proposal is filed, there is no guarantee that all of the required work will be finished and the pull requests merged. Various other teams must agree and we are not a company where we can agree beforehand on stuff being merged.
We have a general “Scope” section, but the details vary between proposals. I would encourage Owners to put links to pull requests there (I do that in my Change proposals for example), but I don’t think we should require this.
Since tuned is going to implement the power-profiles-daemon D-Bus API, we don’t actually need to do anything at all upstream. GNOME can just keep using org.hadess.PowerProfilesDaemon as before, and distros can choose which implementation to use. I doubt we actually want to make UI changes just because the backend has switched from power-profiles-daemon to tuned?
I think it is meant to be implied by “no sooner than a week” in the documented steps. It might be good to instead say something like “When that discussion has concluded, after a minimum of one week…”
So I think the ‘Dependencies’ section of the Change Proposal might be a place where we can explicitly call out the need for a change proposal owner to have engaged with associated teams/projects/packages/other before submitting the change. Perhaps a Yes/No indicator and a request to list those affected, or has the potential to be affected. This might help with the clarification on what is happening before the change proposal becomes public, and gives the folks affected/impacted a chance to add the change to a watch list or something to keep up to date with the discussion that happens.
In terms of the timeline for when a change is submitted to FESCo, its certainly a bit blurry, which has caused a bit of confusion to both change owners and myself (maybe we are all new to this ) as I’ve had a few change owners reach out to me to submit their changes for voting once about a week +2 days have passed as per the documentation, and conversation has either seemed concluded on the discourse topic or not as active, or in this case that scope has changed even mid-discussion, so we could do a few things:
I can start saying ‘not yet’ to people when I am a little more experinced in the flow of the change proposal process (which is any day now, Im sure of it )
We can implement a hard deadline for feedback and then voting
Add a ‘Ready for Fesco’ checkpoint between the Change Wrangler and Proposal Owner
) as I’ve had a few change owners reach out to me to submit their changes for voting once about a week +2 days have passed as per the documentation, and conversation has either seemed concluded on the discourse topic or not as active, or in this case that scope has changed even mid-discussion, so we could do a few things:
)