Xen project Mailing List

It is very helpful if the contributors can post a design document before sending the patches to community,

It has the following advantages:

1. A design document can give people a whole picture of the feature before going to code details, which

Makes it easier to follow the code when doing review.

2. The related maintainers and other contributors can discuss the design, and make an agreement on it.

So that the contributor can do the right thing in the right direction. This can save lots of efforts for both the

maintainers and the contributors.

3. This is the common software development process, design first, then coding.

The whole point of having such design discussions is to get maintainer’s feedbacks as early as possible

and have everyone agree on the solution architecture up front. This approach has worked great when all

relevant maintainers actively participate in the discussions like the case of PML patchset. Our assumption is

that all relevant maintainers agree with the design if they remain silent during design discussion. However,

when we come up with an implementation based on the agreed design and maintainers who did not participate

in design discussion raise design problems later, it really made engineers frustrated and defeated the whole

motivation of having design discussion up front.

Thanks,

Feng

From: xen-devel-bounces@xxxxxxxxxxxxx [mailto:xen-devel-bounces@xxxxxxxxxxxxx] On Behalf Of Lars Kurth
Sent: Tuesday, August 04, 2015 8:53 PM
To: xen devel
Subject: [Xen-devel] [xen 4.6 retrospective] Kicking off a retrospective for Xen 4.6 (deadline August 28th)

Hi all,

I have been asked by a number of people to kick off a retrospective for

* what worked well

* didn't work well

in the Xen 4.6 release cycle.

As most of the stress of the last few weeks is now out of the way, I

thought it would be appropriate to start this process now, and let it run

for a few weeks. We have not done this type of retrospective over e-mail

before (we have done so at developer meetings as well as Hackathons).

As we have a global and distributed community, I think it is worthwhile

trying this by email. To make this work, you need to follow a few ground

rules.

= Ground Rules =

We would like to hear

a) what worked well and

b) what didn't work well

in this release cycle.

Please provide feedback before August 28th.

== What to discuss / what not to discuss ==

* Do NOT send issues which are personal to the mailing list. This means,

do NOT send anything related to individuals or companies that may have

occurred in this release cycle. We do not want to have divisive flame

wars in our community: this does not fit our values and will help

no-one. If you believe that we do have an issue, that requires referring

to individuals/companies, please send me a private email following the

same formatting conventions as outlined below. I can then work with you

to figure out how to best approach this issue or piece of feedback.

* If you are not sure, contact me beforehand and we can discuss the best

way forward.

* It is entirely acceptable to discuss process issues in public. Examples

of topics that are suitable are: "the hard freeze did not work", "the hard

freeze did work well", "we should have longer freeze exception windows",

"we should have no freeze exceptions at all", "we should open master to

contributions after RC2", "we should rename freeze to something else as

it encourages misunderstandings", "we should have a shorter release cycle",

etc. - these are just examples.

* If you agree with an issue/solution you can reply to it with a comment

or a "+1" in the normal way

* If you disagree or have some concerns about what has been proposed,

feel free to reply. You can use the "-1 comment" format.

Please be MINDFUL when you reply to one of the ideas and suggestions that

were raised. The ground rule about NOT becoming personal also applies to

replies.

== Formatting of Mails ==

* Please only cover only *one* topic per feedback e-mail. In other

words please do not mix topics. This makes it easier to collate feedback

and for everyone to follow the threads.

* Use the [xen 4.6 retrospective] tag in the subject line to xen-devel@

* You can use the [good] or [bad] tag in the subject line to xen-devel@

* Make sure you CC community.manager@xxxxxxxxxxxxxx

* Use [private] and the tags above, and do NOT send the mail to xen-devel@

if this is a question/issue ONLY directed at me. This will help me manage

my inbox

* Use [urgent], if your issue should be discussed at the upcoming

Developer Summit Aug 18-19, OR if it is something which affects the current

release cycle (e.g. "we should open master to contributions after RC2")

* Use a descriptive subject line describing the issue/feedback, e.g.

"release cadence was too long", ...

* If you can, reply to this e-mail thread and change the title as

described above. That way, most of the feedback will be nicely threaded

== Content ==

Ideally, you would follow the following template

---

Subject: [xen 4.6 retrospective] ...

= Issue / Observation =

Describe what you have noticed

Described whether this was positive or negative and how

...

= Possible Solution / Improvement =

Describe how you think we could improve the situation

Explain why your proposal would make a positive impact

...

---

== Closing the Discussion ==

I will monitor the post-mortem and I will act as facilitator: for example

I may call out improper behaviour in public or private to keep the

retrospective focussed.

At some point after August 28th, we will look at the issues and

suggestions raised and see which ones we can address and how. For the

ones we can address, we will condense feedback into concrete proposals

which we may put forward for voting (unless everyone agrees that something

is a great idea, or strictly speaking no vote is necessary).

Best Regards

Lars

Re: [Xen-devel] [xen 4.6 retrospective] Kicking off a retrospective for Xen 4.6 (deadline August 28th)