History
When we started Fedora.next, we had the idea of making “Fedora Products”. This presentation from Christoph Wickert at Flock Prague covers it really nicely – you can watch the whole thing for history, or jump to about minute 20 for the part specifically relevant here:
Or if you prefer reading to watching, these Fedora Magazine articles from the time are a good source:
What we asked for originally:
The accepted “Fedora Products” proposal to the Fedora Board is on the wiki. It was approved sometime in 2013. (As a project, we’ve struggled with recording and communicating decisions for a long time. “Slow progress towards the somewhat better!”)
That asked for two deliverables: a PRD which includes a statement of target audience and the role in the Fedora ecosystem, and a list of changes to Fedora procedures needed to make that thing happen. It’s also worth noting John Rose’s — that’s @inode0 — concern that “these three products are not set in stone for the next decade”, and the note from @misc that “we could had a yearly check of the relevance of the project or something like this”.
I can’t find if we actually defined in writing what we meant by “PRD”, exactly. We certainly talked about it a lot, and the resulting Cloud, Workstation, and Server PRDs — although different in structure — I think fit the intended idea well.
A couple of years later, we more formally set the ambitious goal of having annual updates. In retrospect, that didn’t work out.
So, now…
First of all, of course, we dropped the word “product” (for $REASONS). This makes “PRD” kind of a strange term, and perhaps even more esoteric to most people not familiar — and we have plenty of acronyms in tech already! Plus, in the world of product marketing, there’s some arguments about “MRD” vs “PRD” and so on. And, in an actual product organization, a PRD or MRD is a communication from Product Marketing, who does customer and market research to determine the problem to solve, to Engineering, who will then create a functional spec and implement. That clearly doesn’t cleanly map to what we’re doing in Fedora.
So, I’m up for calling this something else going forward. (Feel free to bikeshed on that below. I suggest, with no strong attachment, “Edition Target & Goals”).
Some meta-questions I think we should answer:
- Why are we asking for this? What’s the point?
- Who is the audience of the document?
And then, practical questions:
- What must the document contain?
- What shouldn’t it cover?
-
When, or, really: How can we structure the process so updating the document regularly is:
- not burdensome,
- practically useful to Fedora teams (both the edition WGs and others), and
- something that actually happens?
Are there other question we should think about, both meta and pragmatic?
I am thinking that our eventual output here is in the form of a document with sections titled “Why”, “Who”, “What”, “When”, and “Where”. (That last one not just to complete the 5Ws, but also to make things easier seven years from now when Future Fedora is trying to look back.) You can reply to this however you like, but I think it might be useful to me if you use these headers in your responses.