##Risk Description

= Risk Description =

## Detailed description of this risk and its possible implications.
## E.g. If one of the car's tires suffers a puncture, we may run off the road.

Based on our experiences with the Fedora community so far indicates that the team is very responsive and welcomes any feedback from us. However, it is probably not likely that the DOMS team will be the only team to send them feedback, hence, there is a risk that other parties influence the Fedora development in undesirable, maybe even conflicting, directions, from our point of view.

== When to react? ==

## When must we respond to the risk? E.g. When the event occurs or already when we see the warning signs?
## E.g. We must react if we hear a hissing sound.

We must get react if the Fedora development team begins announcing development of features or design changes which conflict with the requirements of the DOMS project.

== Reaction ==

## Detailed description of how to react on the risk and which actions to take, if it is imminent.

## There exists 4 basic reactions:
## 1: Accept the risk.
## 2: Eliminate the cause to the risk.
## 3: Mitigate the probability or the consequence of the risk.
## 4: Delegate the risk to another party, e.g. by outsourcing it or take out insurance for it.

## E.g. We accept the risk and change the tire if we suffer a puncture.

We can mitigate or maybe even eliminate this risk by getting into a dialogue/discussion with the  Fedora development team to influence their decisions that conflicts with the DOMS requirements. As we are using Fedora for implementation of a (wannabee) TDR then we should have a strong case.

== Responsible Persons ==

The below persons are responsible for continuously monitoring and acting on this risk:

## Add a bullet list with links to the wiki pages of the responsible persons here:
## E.g.
## * [:JohnDoe: John Doe]