#1226 Workstation PRD for approval
Closed None Opened 5 years ago by jwboyer.

= phenomenon =

Submitting the Workstation PRD for approval:

https://fedoraproject.org/wiki/Workstation/Workstation_PRD

Our apologies for being a day late.


Hopefully at least some of the goals of the PRD will be achieved.

+1 from me here as I will not be able to attend the FESCo meeting today.

I'll attend the meeting, but I'd rather put my comments also here.

I agree Workstation must aim on some group of users and developers are good choice. What might be a problem is marketing of Fedora in the future. All future reviews will start by: "Fedora, the developers distribution, not for users, contains ..." It might drove away the group marked as Other users in PRD.

Otherwise good, but there must be close co-operation on containers with other products and also on 3rd party repos (already happening).

I'll simply note, as I have before, that the PRD is not a marketing document. Actual marketing of Workstation will still have to be thought about and done with the respective teams.

Highlighting a few phrases that are not a basis for rejection, but perhaps at least worth discussing.

Being a new product the Fedora Workstation will have its basic rules and targets set through this PRD and thus there will be deviations from some of the traditional policies or rules that the old Fedora project followed.

Does FESCo approving this wording have any effect, and if so, is it desirable?

The working group will also be responsible for defining release schedule while also taking the needs of the other working groups into consideration and the resources available from the Fedora infrastructure team.

So far FESCo has been retaining control of the schedule.

I would like to see a little clarification in the part about theme design (under "Work towards standardizing and unifying the Linux desktop space") about how this works together with the Fedora Design Team and existing and future coordinated branding.

Agreed: defer PRD approval for one week. Request clarification on WG re: 1) schedule autonomy 2) "deviation from some of the traditional rules or policies that Fedora has followed". FESCo has concerns about blanket approval of these statements. (+7,0,0)

Please clearly note those items in this ticket.

One technical note - if you look at the Server and Cloud PRDs, they both specify their deliverables & delivery mechanisms (i.e., what isos or trees/repos they may intend to produce.) The Workstation PRD does not. Is this intentional?

OK, so you had until Friday to submit questions. Here are the questions I've gathered from the ticket:

1) How does the Fedora Design Team play into the standardization work?

2) What is the actual deliverable and delivery mechanism for Workstation?

3) FESCo has said schedules should be kept in-sync for now. Should the release schedule section still be included?

There's another question in mitr's comment, but it seems to be a question for FESCo, not the WG. However, I'll reword it to be:

4) What traditional policies and rules will be modified from the existing Fedora policies/rules?

If that isn't an accurate question, please let me know.

Josh, do you have a response and updated PRD for us to review at the meeting today? I'd like to receive it in advance so we can read it ahead of time.

Replying to [comment:9 sgallagh]:

Josh, do you have a response and updated PRD for us to review at the meeting today? I'd like to receive it in advance so we can read it ahead of time.

Not at the moment. Considering nobody from FESCo commented anything further by Friday, I left it to go over the weekend in case people were busy. Then I summarized things and received no other response, so I've sent my own list of questions to the WG to work on them. Talking into a void is rather frustrating.

I'll see what we can get accomplished by today.

my apologies Josh, to make explicit what I've been thinking: your summary of mitr's comment, number 4, is the heart of the problem I see with this draft. the draft seems to be hinting that the workstation wg will be making decisions that fesco hasn't allocated to it. on my first read through, that problem seemed to permeate much of the underlying thinking of the draft. on subsequent reads I see a few things that might make it better:

  • strike the last two sentences of mission statement. they're setting the tone that is problematic.
  • core platform components section: some of these decisions were things that past fesco decisions were imagining would be handled through the base design wg. others are things that fesco might (or might not) want to have oversight on.
  • I'd imagine that base design would take input from other wg, users, and contributors and come up with a list of packages and services that it considers are the "api and services" promise for any product calling itself fedora. on top of that, they'd review and for the most part approve additional "api and services" that individual products want to implement to be sure that the fedora family of products have some sort of consistency.
  • the treatment of optional packages needs fesco to decide how much oversight they want and whether some implementations are not allowed. current fedora doesn't prevent the user from changing defaults to things that are wildly different so fesco needs to decide whether they'd like to allow an individual product to change that expectation.
    -work model: at the meeting I mentioned the fedora change process because of this section. it read like it might be circumventing the change process. I think changing the overall tone of the prd by removing the two sentences of the mission statement fixes this. (the workstation wg is not planning to circumvent the change process, correct?)
  • other tasks:
  • release schedules has already been mentioned.
  • meeting with a red hat designate is really something that needs to happen in fesco. it's something that informs the technical direction of all of fedora. having just one subgroup of fedora that is in tune with what red hat wants and needs while the rest of fedora is marching to a different time is a recipe for eventual disaster.
  • the packaging for workstation section has similar problems to the core platform components section and could use a little rewording as well. fesco needs to decide what mechanisms for preventing software from installing are allowed.
  • I can't imagine fesco would approve a mechanism that operated at the level of telling people they could not package a piece of software for fedora. so wording wise, this section should probably talk about preventing installation of packages that break the core workstation system.

Replying to [comment:11 toshio]:

my apologies Josh, to make explicit what I've been thinking: your summary of mitr's comment, number 4, is the heart of the problem I see with this draft. the draft seems to be hinting that the workstation wg will be making decisions that fesco hasn't allocated to it. on my first read through, that problem seemed to permeate much of the underlying thinking of the draft. on subsequent reads I see a few things that might make it better:

  • strike the last two sentences of mission statement. they're setting the tone that is problematic.

I'm going to assume you mean the last sentence because the penultimate sentence is entirely reasonable. The PRD is a living document that will naturally undergo revisions. I'm not removing that.

  • core platform components section: some of these decisions were things that past fesco decisions were imagining would be handled through the base design wg. others are things that fesco might (or might not) want to have oversight on.

I'm going to point out that if FESCo feels it has to approve every possible change the products do then they might as well disband the WG. There's no point in trusting others with a domain specific product if you don't trust them to make appropriate changes for that product.

  • I'd imagine that base design would take input from other wg, users, and contributors and come up with a list of packages and services that it considers are the "api and services" promise for any product calling itself fedora. on top of that, they'd review and for the most part approve additional "api and services" that individual products want to implement to be sure that the fedora family of products have some sort of consistency.

I'm on the Base WG. There's been no discussion at all about approving or reviewing API/service layers above what Base provides. Speaking from both a Base and Workstation perspective, I don't think Base has any business dictating what products may wish to implement on top of Base. Base is the consistency layer.

  • the treatment of optional packages needs fesco to decide how much oversight they want and whether some implementations are not allowed. current fedora doesn't prevent the user from changing defaults to things that are wildly different so fesco needs to decide whether they'd like to allow an individual product to change that expectation.

This is confusing and misleading. Users can change defaults, sure. However, the section is talking about optional packages inside the Workstation product overriding things that Workstation relies on in the context of the Workstation product. If someone installs a package from outside the Workstation set that breaks things fine (we can't prevent people from breaking their system however they wish). But it is not unreasonable for optional packages within the Workstation set to not conflict or replace things Workstation relies on.

-work model: at the meeting I mentioned the fedora change process because of this section. it read like it might be circumventing the change process. I think changing the overall tone of the prd by removing the two sentences of the mission statement fixes this. (the workstation wg is not planning to circumvent the change process, correct?)

I've yet to see evidence that the Change process would not be used. I've also yet to see evidence that the Change process makes sense in a product world. Denying a PRD based on the fact that nobody knows what the Change process means seems to be pushing the problem on the wrong group.

  • other tasks:
  • meeting with a red hat designate is really something that needs to happen in fesco. it's something that informs the technical direction of all of fedora. having just one subgroup of fedora that is in tune with what red hat wants and needs while the rest of fedora is marching to a different time is a recipe for eventual disaster.

Then FESCo can certainly take that upon themselves. When would you like to schedule meetings with the various areas within Red Hat for Workstation, Cloud, and Server? Until that happens (or perhaps in addition to it), having contact with the group within Red Hat that is providing the majority of the initial resources for this product seems to be a rather good idea, in much the same way that it's good to have contact with upstream projects (release cycles, project directions, etc).

  • the packaging for workstation section has similar problems to the core platform components section and could use a little rewording as well. fesco needs to decide what mechanisms for preventing software from installing are allowed.
  • I can't imagine fesco would approve a mechanism that operated at the level of telling people they could not package a piece of software for fedora. so wording wise, this section should probably talk about preventing installation of packages that break the core workstation system.

Suggestions welcome.

None of this feedback can be addressed today. It should have been made last Friday, like we agreed.

I've made some edits to the wiki to clarify the things asked in the questions present in comment #8.

  • 1226 Workstation PRD for approval (sgallagh, 18:53:06)

  • AGREED: Approve the current version of the Workstation PRD (+5, 1,
    -1) (sgallagh, 19:00:17)

Login to comment on this ticket.

Metadata