#504 Request to upgrade Fedora KDE Desktop Spin to Edition status under the Personal Systems WG
Closed: approved 24 days ago by amoloney. Opened 3 months ago by ngompa.

As discussed at Flock, the Fedora KDE SIG and the newly forming Fedora Personal Systems Working Group that will oversee the SIG are requesting that the Fedora KDE Plasma Desktop spin be upgraded to Edition status for Fedora Linux 42.

This includes the following:

  • Listing Fedora KDE Plasma Desktop Edition at the same level as Fedora Workstation Edition on fedoraproject.org
  • Production of a flagship site page for Fedora KDE similar to Fedora Workstation on fedoraproject.org
  • Marketing support in a similar vein to Workstation at events

The Fedora KDE SIG will withdraw its Change for Fedora Linux 42 to replace GNOME with KDE Plasma on Workstation with the acceptance of this request.


I've created a topic on Fedora Discussion for this ticket.

Please keep this ticket focused. Discuss there, and record votes and decisions here. Thanks!

Metadata Update from @amoloney:
- Issue tagged with: Needs Review, policies

3 months ago

It's s been discussed and met with good reception in general and now that the editions policy allows for a bit more flexibility, I think the discussion on discourse both on the initial change proposal thread and on the thread about this request clearly demonstrates there is an appetite for KDE as an Edition. So I'm +1

This decision needs full consensus. See https://docs.fedoraproject.org/en-US/council/#decisions.

Please also keep https://docs.fedoraproject.org/en-US/council/policy/edition-promotion-policy/ in mind as you vote.

As @jflory7 points out, we should have given a time limit for full consensus in the decision-making policy, which was not written with the consideration that some Council members may be difficult to reach at the time the decision needs to be made. There is a provision for deadlocks, which we could arguably use if necessary — that sets a 14-day upper bound. But I'm going to try (with all of your help!) to get all of the votes in as soon as possible.

I am +1 to promoting KDE as an edition, because I've seen the hard work the KDE SIG has put in, and the polished results. I think there is room for two Editions in this space and that it will be net growth for Fedora, not a zero-sum game fighting over Fedora users.

I do have two caveats.

First, although the plan calls for keeping the same quality bar to reduce impact on the Quality Team, Editions should represent the project showcasing our most polished efforts. I would like to see us target the same high standard, and I'm confident that KDE can meet it. But, we will need to ensure that this is reasonablefor the Quality Team. (Not just on the KDE side; I'd like to see more validation effort from the Workstation team, too, so that Quality Team can take more of a facilitation and consulting role in both.) If we're not comfortable saying that we can handle "top-billing" validation for F42, we should defer to F43.

Second, we need a plan to develop a marketing story and a way to present the two Editions that isn't confusing. This is a hard problem, and while frankly I have no idea how to solve it, we've got smart people and I think we can figure something out. But, I want to see this in a plan including the Marketing Team and Website & Apps team, and we (the Council) need to make sure that work stays on track. If it isn't settled in time for the F42 beta launch, we need to defer to F43.

Also, I'm against a Personal Systems WG which does not include at minimum all Desktop Editions. That needs to be worked out.

I am +1 to promoting KDE as an edition, because I've seen the hard work the KDE SIG has put in, and the polished results. I think there is room for two Editions in this space and that it will be net growth for Fedora, not a zero-sum game fighting over Fedora users.

I do have two caveats.

First, although the plan calls for keeping the same quality bar to reduce impact on the Quality Team, Editions should represent the project showcasing our most polished efforts. I would like to see us target the same high standard, and I'm confident that KDE can meet it. But, we will need to ensure that this is reasonablefor the Quality Team. (Not just on the KDE side; I'd like to see more validation effort from the Workstation team, too, so that Quality Team can take more of a facilitation and consulting role in both.) If we're not comfortable saying that we can handle "top-billing" validation for F42, we should defer to F43.

Second, we need a plan to develop a marketing story and a way to present the two Editions that isn't confusing. This is a hard problem, and while frankly I have no idea how to solve it, we've got smart people and I think we can figure something out. But, I want to see this in a plan including the Marketing Team and Website & Apps team, and we (the Council) need to make sure that work stays on track. If it isn't settled in time for the F42 beta launch, we need to defer to F43.

Also, I'm against a Personal Systems WG which does not include at minimum all Desktop Editions. That needs to be worked out.

So, I'm 100% with you on most of this, minus the last sentence (kindof). We're already making efforts to onboard users that will help us do QA work. I personally invested close to $2500 in ARM hardware that should be validated in the mainline kernel by the release of 42, so that will allow me to do QA testing.

Now, for that last sentence.... to be honest, I don't think the KDE sig objects to this (I don't), but... I don't see the "gain" of putting the KDE and Gnome edition together (Honestly, the only thing we have in common right now is Neal imo, otherwise we don'T really communicate as-is)

But for the sake of having a homogenous(sp?) team, I agree in principle to that last sentence. Do the Desktop and Server teams work together in some way?

Sorry if I'm missing the point.

It doesn't actually make sense to force everyone into the same group. The Personal Systems WG already has plans for expansion and at least two SIGs will be part of it at launch. There are growth prospects for multi-stakeholder relevance, but forcing it is not part of the plan.

Not to mention, we already don't do this for any of the server-side teams: CoreOS, Cloud, and Server are not forced under a single banner either. It is unreasonable to require that for us.

+1 to the upgrade as well!

First, although the plan calls for keeping the same quality bar to reduce impact on the Quality Team, Editions should represent the project showcasing our most polished efforts. I would like to see us target the same high standard,

Well that didn't take long for my words (about somebody soon requesting it) to come true :-) Please bear with me, I'll be specific here. One of the major differences in our current release criteria is the default application functionality. It lists 11 major apps which must work, but please note this very important paragraph:

Additionally, for Fedora Workstation on the x86_64 architecture, all applications installed by default which can be launched from the Activities menu must meet this requirement.

For Workstation, this is extra 22 apps to test. It is one of the least popular test cases, which means it is done infrequently and late, because it takes a long time, it's vague ("basic functionality" is a judgement call and a constant source of trouble, but we don't know how to define it better) so you don't exactly know what to test, and it's easy to sink a lot of time in it when finding and reporting a bug which is then waived by others as inconsequential.

For KDE, this would be extra 51 apps! Compare the scope. I believe it's impossible for us to have the same quality bar here. And even if we had a huge surge of volunteers to test those regularly, it would just mean that we'd hardly ever release, because the likelihood of discovering a broken functionality in 73 apps (22+51) is much higher than in 22 apps. Workstation is quite lean on pre-installed apps, and yet we already struggle with this, and many people get irked by the whole compose being blocked on a bug in gnome-clocks/gnome-contacts/gnome-calendar/etc.

So I don't realistically see how we can have the same release criterion for KDE. Either the quality requirements won't be the same, or we need to lower the Workstation one and meet somewhere in the middle for both. (Maybe this criterion is ready to be changed anyway, because it's causing many disagreements, but it was Workstation WG who requested it in the first place, long time ago).

Sorry for a long reply, but I wanted to demonstrate our concerns on an a concrete example. Please everyone keep it in mind when talking about "the same high standard". There will be places where the bar will have to be lowered, if the scope increases. If this is OK by Fedora at large, then no problem (although it might make some groups unhappy). I just want to be honest about this.

(Let's not discuss possible changes to this particular criterion here, that's off-topic for this ticket. We'll have a QA ticket for it.)

First, although the plan calls for keeping the same quality bar to reduce impact on the Quality Team, Editions should represent the project showcasing our most polished efforts. I would like to see us target the same high standard,

Well that didn't take long for my words (about somebody soon requesting it) to come true :-) Please bear with me, I'll be specific here. One of the major differences in our current release criteria is the default application functionality. It lists 11 major apps which must work, but please note this very important paragraph:

Additionally, for Fedora Workstation on the x86_64 architecture, all applications installed by default which can be launched from the Activities menu must meet this requirement.

For Workstation, this is extra 22 apps to test. It is one of the least popular test cases, which means it is done infrequently and late, because it takes a long time, it's vague ("basic functionality" is a judgement call and a constant source of trouble, but we don't know how to define it better) so you don't exactly know what to test, and it's easy to sink a lot of time in it when finding and reporting a bug which is then waived by others as inconsequential.

For KDE, this would be extra 51 apps! Compare the scope. I believe it's impossible for us to have the same quality bar here. And even if we had a huge surge of volunteers to test those regularly, it would just mean that we'd hardly ever release, because the likelihood of discovering a broken functionality in 73 apps (22+51) is much higher than in 22 apps. Workstation is quite lean on pre-installed apps, and yet we already struggle with this, and many people get irked by the whole compose being blocked on a bug in gnome-clocks/gnome-contacts/gnome-calendar/etc.

So I don't realistically see how we can have the same release criterion for KDE. Either the quality requirements won't be the same, or we need to lower the Workstation one and meet somewhere in the middle for both. (Maybe this criterion is ready to be changed anyway, because it's causing many disagreements, but it was Workstation WG who requested it in the first place, long time ago).

Sorry for a long reply, but I wanted to demonstrate our concerns on an a concrete example. Please everyone keep it in mind when talking about "the same high standard". There will be places where the bar will have to be lowered, if the scope increases. If this is OK by Fedora at large, then no problem (although it might make some groups unhappy). I just want to be honest about this.

(Let's not discuss possible changes to this particular criterion here, that's off-topic for this ticket. We'll have a QA ticket for it.)

Yeah I'm not gonna discuss at length here as, as you said, it's off-topic, but I doubt we can test every single app in the KDE stack. That would be wholly unreasonable.

We already don't test every single app in the GNOME ecosystem packaged in Fedora either.

There might have been some misunderstanding, so I'll just highlight once again that my example wasn't related to "all packaged GNOME/KDE apps" or anything similar. The criterion for Workstation reads "all applications installed by default which can be launched from the Activities menu", as printed in full above.

In order to keep this ticket from being too confusing, please keep discussion to https://discussion.fedoraproject.org/t/fedora-council-tickets-ticket-504-request-to-upgrade-fedora-kde-desktop-spin-to-edition-status-under-the-personal-systems-wg/131059.

Including my with-caveats vote, we are at +3 now, which is the minimum threshold; if we don't get any objections by November 7th, I will consider this approved. But I'd still like to get in more official council votes before then!

In order to keep this ticket from being too confusing, please keep discussion to https://discussion.fedoraproject.org/t/fedora-council-tickets-ticket-504-request-to-upgrade-fedora-kde-desktop-spin-to-edition-status-under-the-personal-systems-wg/131059.

Including my with-caveats vote, we are at +3 now, which is the minimum threshold; if we don't get any objections by November 7th, I will consider this approved. But I'd still like to get in more official council votes before then!

Question about your caveats, Matt. What if the Workstation WG says "No way, Jose, no chance Lance"?

I am +1 to promoting KDE as an edition, because I've seen the hard work the KDE SIG has put in, and the polished results. I think there is room for two Editions in this space and that it will be net growth for Fedora, not a zero-sum game fighting over Fedora users.

I do have two caveats.

First, although the plan calls for keeping the same quality bar to reduce impact on the Quality Team, Editions should represent the project showcasing our most polished efforts. I would like to see us target the same high standard, and I'm confident that KDE can meet it. But, we will need to ensure that this is reasonablefor the Quality Team. (Not just on the KDE side; I'd like to see more validation effort from the Workstation team, too, so that Quality Team can take more of a facilitation and consulting role in both.) If we're not comfortable saying that we can handle "top-billing" validation for F42, we should defer to F43.

Is this unique to KDE? We kind of hold everything to this. The KDE group is already doing this work such that it's usable and polished in Fedora. We have many instances in the past of having to make a hard decision of determining something in not ready for a release and then back it out or reclassify it or something like that. Those are never easy decisions. But I don't think we need a finger-wag for KDE to remind them to do a good job. They are and I don't see how this work is any different than what other groups do.

Second, we need a plan to develop a marketing story and a way to present the two Editions that isn't confusing. This is a hard problem, and while frankly I have no idea how to solve it, we've got smart people and I think we can figure something out. But, I want to see this in a plan including the Marketing Team and Website & Apps team, and we (the Council) need to make sure that work stays on track. If it isn't settled in time for the F42 beta launch, we need to defer to F43.

I agree that a marketing story to explain the two Editions is necessary, but I don't think that's KDE SIG's sole responsibility. They should be involved, yes, but I don't think holding up promotion of KDE to an Edition should be blocked by the marketing story. We can promote it and work on the marketing later. It's ok to have the KDE Edition available for download via links like dl.fedoraproject.org until we have the marketing story done.

Also, I'm against a Personal Systems WG which does not include at minimum all Desktop Editions. That needs to be worked out.

I am not 100% familiar with the Personal Systems WG. I trust our community members to self-organize in a way that works for the projects involved. If this works well now, fine. If it needs to
change, I trust that will happen.

I am +1 to the change otherwise.

I am +1, given that

1) Personal Systems WG will work with the Fedora QA to define some feasible generic criteria for the "default application functionality" and similar items on the release checklist

2) Personal Systems WG will collaborate with the Marketing and Design teams on the marketing strategy which includes multiple Editions

Question about your caveats, Matt. What if the Workstation WG says "No way, Jose, no chance Lance"?

In that case, please use a more specific name ("KDE Edition WG", say) for now, and the Council will need to take on the bigger issue.

I do not want to do that. We have plans for the WG, and I've spent months working on that. The Workstation WG has a non specific name, and I want our group to have the same privilege. We already conceded to leaving our edition as the KDE Plasma Desktop Edition, as that was not our original plan either.

And by that rule, then you'd need to also rename the "Workstation WG" to "Gnome Edition WG" or this makes very little sense consistency-wise... And if merging both WGs is no longer an immediate concern, I don't think the name shouldn't keep this decision from going through...

For the record though, I do personally agree that, at some point, all desktop editions should be reunited under the same general banner, but.... I see that as being quite a ways down the road...

Well we already are: Fedora.

I am +1 to this edition promotion.

Further:
I would like to decouple the discussion on the Personal Workstations WG membership from this vote.
I would also like to recognise @kparal's comments of needing to be mindful of the QA scope, but see no immediate risk to the projects brand integrity by promoting KDE as it is to Edition at the current release 'bar' they are meeting, as I have known the SIG to produce a high quality spin on each release. This concern is also derisked by the confirmation of buy-in from Fedora QA to KDE to keep validation testing at the current status quo.*
And, I support the suggestion of creating a good, unique marketing story for each edition, not just the two workstation ones :) Im happy to be involved in this effort when it becomes a reality.

*The criteria for edition status 'quality' is too vague to justify blocking this promotion. Lets deal with that separately and see how the KDE Edition is received before we add extra criteria to the promotion framework.

+1

Agree with @mattdm about the need of developing a good marketing story. An example that's easy to see: There are laptops shipping Fedora pre-installed. Before this change, the Workstation Edition was a clear choice. But what will be our guidance for after this change? And so on.

Naming, renaming, and merging working groups is — as far as I'm concerned — outside of this vote. The current Personal Systems WG is full of competent people who can make the edition a success, regardless their name.

This request can now be considered APPROVED (+9, 0, 0).

Discussion around other factors that this promotion have highlighted as needing attention can continue async from this request.

Metadata Update from @amoloney:
- Issue untagged with: Needs Review, policies
- Issue close_status updated to: approved
- Issue status updated to: Closed (was: Open)

24 days ago

Thank you everyone for your hard work, serious consideration, and patiently on this. Now for the hard part! :)

Log in to comment on this ticket.

Metadata