# Konveyor Workflow Raw Notes
###### tags: `Mtg Notes`

## 3/23
Where is PRD content actually defined? Split up across Epics and Stories?
One single document, <jeff> it's tremendously helpful to have a single document
(the enhancement). Jiras were created as pointers into the enhancement document
so that QE could work their lifecycle off of the QE.
+1 Phil, the enhancement document was extremely useful, cohesive document.
Take the user-stories that are in that document and those would get mirrored
into Jira, and then those user stories get implemented. In Jira, the acceptance
criterea is defined on the stories.

<Daniel> Like this PRD document, missing important abilities like prioritization.
Everything that you want to do with Jira is possible because the PRD doc is
chopped up and watched by a bot that reconciles the state of the PRD with the
state of what's inside of Jira.

Marco Q: Meeting with a customer, I don't want to set in stone in the doc,
can I park something for a future. It's a good idea, how does it make it's way
into the PRD? Customer requests a feature to be added, take that, take verbatim
great idea add directly to PRD?

Isn't it just a github issue that gets created?

<Jeff> Perspective of the RFE: if they're expressing a wish and it's got private
customer details, it can just remain in Jira. To solve this customers problem,
we can generically enhance the product and that gets written into the PRD.
It has to be mature when/if it goes into the PRD.

If we're going through the trouble to design a process that encourages external
contribution, we should be deliberate about encouraging people from outside the
team to contribute. We have to be intentional about walking these people through
our process to do that.

https://github.com/konveyor/enhancements/pull/62
How do we make sure that something like John is trying to do here as an "external"
contributor is still possible?

Summary:
In agreement that the PRD is something that's important and needed.
Unsure exactly where it's created and/or how. Jeff finds it very helpful.
Ramon has some good examples of that in enhancements.
-> Jira? Google doc? Markdown? What's the authritative source?
How do we communicate these PRDs to an external audience? Github just does not
feel very good for that. Google docs feels very good for document collaboration.

We have some tackle interest -- did those contributors get added to the Konveyor
avenues and encouraged to contribute via the process we have outlined?
Somewhat shy about their involvement. MS asking about governance, they will be
involved.

<Marco> What is an example of a "good" PRD? Is it written every time we do a new release?
I assume it's not done for z streams? If it doesn't exist we need to figure it
out...problem is there's probably tons of examples of this. It's also not
the full picture. PM is responsible for PRDs, and eng needs to flesh out
the functional spec.

Somebody has to be resonsible for the different parts of the puzzle.
MTV compared to Tackle. MTRHO requires a lot more work, MTV probably very little.

Worried about complexity and overhead.

Ramon shared the functional spec:
https://github.com/konveyor/enhancements/tree/master/enhancements/tackle/tackle-windup-integration#functional-specification

Is there *actually* a need to standardize? Well maybe there's a shared template,
and parts of it aren't for specific projects so the answer is N/A

>>
We need this PRD to be detailed and granular enough that QE and go read and author
their test cases, and documentation teams can read and write their docs prior
to a release
<<

Non functional reqs vs. functional reqs
Need some way to spawn out epics and/or stories from those PRDs. In those
Epics, and if it's enough in detail, can fill out epic template from the PRD,
and then you can start to assign out QE tickets. Acceptance criteria.

## 3/30 Notes

Recap, how much of this is done upstream vs. downstream, is there a sync process
for us to keep things in lock step.

<Marco> Another q: There is stuff that's going to distinct to downstream vs.
upstream, the downstream product is different. It's not exactly the same in
both upstream and downstream. Todd +1, possible additional downstream reqs
and we have to account for that.

Start in google docs, once it's solidified that gets published to github.

Here's a doc that outlines the problem, what is needed
Benchmark: Needs to be in-depth enough for QE team to be able to author their
tests.
<John> A lot of churn when its rough as we're learning. What are we building
what are the requirements.

Sprints to clarify things with spikes.

<Todd> We shouldn't commit to delivery dates until that document is written
and as long as we have this eng churn, only until the requirements are solid
we can't really commit to dates.

Marco -- with dates we're trying to roughly set some expectations

We can't set dates until we have this document with consensus and merged.

Doc created in google docs through period of back and forth until we've got
something is representative of what we want to deliver at a specific time.

Golden source
High level golden source in github

PRD
Daniel wants in Jira
Ramon wants to continuously keep the golden source updated in github.
<John> We need to have the conversation on the tasks on pieces of that in Jira.

Feels not practical that we are going back to a golden source and update.
Definitive govt document of all the shalls as a legal contract.

Ramon feels Tackle 2.0 has been a good example of this being successful.
Daniel still needs something in Jira.

<Marco> We have downstream differences with MTRHO vs. crane, do those reqs
make their way back to github?

<Jeff> Pushback defining requirements in the enhancement, not necessarily
viable because of the iterative nature.

Need something better than winging it but we need something that documents
what we're going after, but after we learn more, do we go back to the enhancement
as a contract after we've learned things?

<Jeff> I never viewed that enhancement as a be-all-end-all, we just submitted
things back against the enhancement to update it as we learn more. In the
enhancement we see the entire thing, Jira cards give structure and provide
the tracking facilities for dev / QE to break things down.

<John> Never seen at RH take an initial thing and then go back and update
the doc, maybe a deficiency and we should do that.

<Jeff> We have to have *something* that we all collaborate on where it
contains what's been asked for, something that QE/docs can look at.

! We have to stay away from several places and not keep them up to date !

Todd -- that's not the way that we've been doing it, observation something
is broken or we wouldn't been having this meeting. <John> wants to be careful
that a lot of time that gets spent is not wasted, enormous amount of time
that goes into govt docs, tackle doc, amount of time that was spent on that
is that worth the time that's spent on that?

Why can't doc just use the sprint demos?
Need much more details, the sprint demos is not sufficient.

Is a PRD doc at the level that it has to be at for QE / Doc to write what they
need?

We're missing a document that outlines the supported backends.
If we want to describe in a PRD all the different permutations of things that
can.

Several perspectives that are conflating different concepts.
Are we buildng the right product, do we have the right things that are inside
of that. Once we start to get into losing a lot of time supporting other teams
and be the bridge that provides that bridge. That starts to get a lot harder.

Functional spec, maybe that's provided by the enhancement doc.
Biting off a lot.

Docs doesn't know what to document, PRD wouldn't necessarily solve that.
List of all storage that we want to support.
^ That sounds a lot like requirements, I don't know how that wouldn't be
part of a product requirement doc.

<Ramon> How do you do this with a team that doesn't have any knowledge about
a problem space. Such as Jeff's team who isn't familiar with the Tackle space,
needed to provide as much detail as possible.

<Jeff> Had Ramon not written this up in the detail that he did, Jeff would
have had to spend hours of time on writing docs for people outside of the
team such as QE and docs. How do you not spend the time up front when it can
get a lot more painful later.

<Todd> GDocs is a nice way to collaborate up front. Tackle process done in
github. Was it a pain point in github, once it's solidified in gdocs, once
we were confident it got into Tackle.

MTC/MTV got delivered
Jeff -- someone did all the same levels of effort to document all the things
that Ramon documented, but the can got kicked down the road and it's done
later, could have been redundant. Less efficient.

Phil -- Requirements POV we have to capture nonfunctional reqs. If it's not in
that doc explicitly we can support as a best-effort but it's not supported at
the same level. What is definintely in scope needs to get doc'd.

Functional specification, likes the Tackle approach. Has its place in greenfield
development, Ramon had a clear picture and articulated very clearly what he
wanted in this doc. Not always the case where we're starting with this brand
new.

<Phil> Project initiation doc -- define your approach. That will inform whether
or not you need a PRD, you going to work out of github etc. Is that one of the
things.

Before we get to the point that we're talking about dates.
Goal is to get to a requirements freeze.

Assume we prob need a min of ~3 months past having a PRD together to target a
date.

Summary:
A lot of discussion trying to figure out multiple problems. Where do we go from
here to make some forward progress.

John decide and document the problems that we need to focus on.
Several problems raised on the call.

How do we define a PRD. Functional requirements for PRD.

Todd will take point on a captured list of problems heard on the past few
conversations. What are the problems that are impacting the most people.
Let's tackle those first.