All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joseph Reynolds <jrey@linux.ibm.com>
To: Andrew Jeffery <andrew@aj.id.au>
Cc: openbmc@lists.ozlabs.org,
	openbmc <openbmc-bounces+jrey=linux.ibm.com@lists.ozlabs.org>
Subject: Re: [Proposal] End-user impacts and change log + details
Date: Thu, 04 Apr 2019 12:10:05 -0500	[thread overview]
Message-ID: <6c85b58ebad62f17ee67071e173904ee@linux.vnet.ibm.com> (raw)
In-Reply-To: <8b23543286a12cfa90186efe08039f8c@linux.vnet.ibm.com>

On 2019-03-01 15:22, Joseph Reynolds wrote:
> On 2019-02-27 17:10, Andrew Jeffery wrote:
>> On Wed, 27 Feb 2019, at 01:52, Joseph Reynolds wrote:
>>> This is a proposal to improve OpenBMC communication and get better
>>> release notes.
>>> 
>>> ** Preamble **
>>> 
>>> Teams that use OpenBMC in other projects will not know OpenBMC as 
>>> well
>>> as the development community, and they will not know what is in each
>>> release.  The main way for them to find out is by reading the release
>>> notes.  They will make decisions based on its contents.  That makes 
>>> the
>>> release notes an important communication between the development
>>> community and its end-users.
>>> 
>>> We need to get better at communicating new and changed OpenBMC
>>> functions.  Doing so gives many benefits, including better release 
>>> notes
>>> [1].
>>> 
>>> ** The proposal **
>>> 
>>> 1. Adopt a new practice to provide end-user impact statements when 
>>> and
>>> where it make sense to do so.
>>> 2. Begin a project level change log to summarize user impacts.
>>> 
>>> ** Details **
>>> 

...snip...

I am no longer pursuing end-user impacts statements in each issue at 
this time. Instead I create a work-in-progress wiki.  I'll start a 
separate email thread to announce that.

>>> 
>>> 2. Create a change log from end-user impact statements.
>>> 
>>> Groups who care about end-user impacts include testers, security 
>>> folks,
>>> release managers, and others.  They can scan the issues, read the 
>>> impact
>>> statements, and use them to curate a change log [2] which lists all
>>> changes that might be interesting to users.  Each change log entry
>>> should have a brief description of the impact (from the user's point 
>>> of
>>> view) with links back to the issue.  The change log could be an 
>>> openbmc
>>> wiki page.  (And yes, some people's job includes curating change 
>>> logs.)
>>> 
>>> We should have a project-wide change log which captures all impacts.
>>> (It is easy to ignore entries you don't care about.)  Anyone who 
>>> cares
>>> about a user impact can add items to the change log.
>>> 
>>> How is the change log useful?  Testers will use the change log to 
>>> help
>>> ensure test coverage and add facts about where the test cases are 
>>> stored
>>> and whether the tests passed.  Release managers will use it to gauge
>>> progress toward goals.  Security folks will cover security changes.
>>> Technical writers, etc.  Each will contribute significant facts about
>>> their part of the process, and the log is a place to organize links 
>>> to
>>> demos, etc.
>>> 
>>> 3. Use the change log to make release notes.

...snip...

> 
> Here is the next level of detail:
> 
> 1. Add the "change log process" to the CONTRIBUTING doc [101].
>  - Motivate the need to document end-user impacts and for a change log,
>    and show how these flow into the release notes.
>  - Provide guidance for the content of user impact statements.
>    Give examples of impacts, non-impacts, and end-users.
>  - Say where to document impacts (in github.com/openbmc/REPO/issues).

...snip...

> 4. Create the Change Log wiki here:
> https://github.com/openbmc/openbmc/wiki/changelog
> and begin to populate it with user impact.

This is done.  I'll start a new email thread to announce it.

- Joseph

> I am interested in this a way to track the software development
> process.  Specifically, I would create user impact statements and
> changelog entries for:
>  - Release 2.7 work items as they complete, tracked here: [103].
>  - Functions being tracked by the test work group [104].
>  - Security impacts [105].
> 
> - Joseph
> 
> [101]: https://github.com/openbmc/docs/blob/master/CONTRIBUTING.md
> [102]: https://help.github.com/en/articles/mentions-on-github-pages
> [103]: https://github.com/openbmc/openbmc/labels/Release2.7
> [104]: https://github.com/openbmc/openbmc/wiki/Test-work-group
> [105]:
> https://github.com/openbmc/openbmc/wiki/Security-working-group#current-development-work-with-security-impact
> 
>> Andrew
>> 
>>> 
>>> - Joseph Reynolds
>>> 
>>> [1]: https://en.m.wikipedia.org/wiki/Release_notes
>>> [2]: https://en.m.wikipedia.org/wiki/Changelog
>>> [3]: https://github.com/openbmc/openbmc/wiki/Release-Planning
>>> [4]:
>>> https://github.com/openbmc/docs/blob/master/release/release-notes.md
>>> [5]: https://en.wikipedia.org/wiki/Software_security_assurance
>>> [6]: https://github.com/openbmc/openbmc/wiki/Test-work-group
>>> [7]: https://github.com/openbmc/openbmc/wiki/Security-working-group
>>> [8]: https://help.github.com/en/articles/about-labels
>>> [9]: https://github.com/openbmc/openbmc/labels
>>> 
>>> 

      parent reply	other threads:[~2019-04-04 17:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-01 21:22 [Proposal] End-user impacts and change log + details Joseph Reynolds
2019-03-03 22:19 ` Andrew Jeffery
2019-03-04 15:20 ` Sivas Srr
2019-04-04 17:10 ` Joseph Reynolds [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6c85b58ebad62f17ee67071e173904ee@linux.vnet.ibm.com \
    --to=jrey@linux.ibm.com \
    --cc=andrew@aj.id.au \
    --cc=openbmc-bounces+jrey=linux.ibm.com@lists.ozlabs.org \
    --cc=openbmc@lists.ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.