git: ee5c2fd574 - main - 2024q2 report: fix github report markup

From: Warner Losh <imp_at_FreeBSD.org>
Date: Sun, 14 Jul 2024 05:38:09 UTC
The branch main has been updated by imp:

URL: https://cgit.FreeBSD.org/doc/commit/?id=ee5c2fd574749dad24d558eaba37a9783e832003

commit ee5c2fd574749dad24d558eaba37a9783e832003
Author:     Warner Losh <imp@FreeBSD.org>
AuthorDate: 2024-07-14 05:26:23 +0000
Commit:     Warner Losh <imp@FreeBSD.org>
CommitDate: 2024-07-14 05:37:26 +0000

    2024q2 report: fix github report markup
    
    The bullet list wasn't rendering properly, so fix that.  Also, although
    done in the first week of july, we can now do multiple pull requests in
    one staging branch for CI batch testing, so add that to what we've done,
    turning that into a bullet list as well. Tweak the lists a little to
    tighten them up. Add encouragement to join us after telling people
    where.
    
    Noticed by: graham perrin (bullet markup)
    Sponsored by: Netflix
---
 .../en/status/report-2024-04-2024-06/github.adoc   | 29 ++++++++++++++--------
 1 file changed, 19 insertions(+), 10 deletions(-)

diff --git a/website/content/en/status/report-2024-04-2024-06/github.adoc b/website/content/en/status/report-2024-04-2024-06/github.adoc
index 5ea8718009..f484bbbffe 100644
--- a/website/content/en/status/report-2024-04-2024-06/github.adoc
+++ b/website/content/en/status/report-2024-04-2024-06/github.adoc
@@ -11,20 +11,29 @@ We have learned a lot in the last year that we've been doing this.
 We have created a number of rules relating to the pull requests.
 In general, pull requests should only be for things that are user-visible, add value to the project and are ready to go, modulo final review.
 
-At this point, we are able to keep up with the pull requests doing everything by hand.
-However, this has proven to be tedious and error-prone.
-While the vast majority of the pull requests have been fine, we have introduced a few problems.
-We have started working on scripting to automate staging and landing in the tree.
+Current status:
+
+* We are able to keep up with the pull requests doing everything by hand, but only if do it at least weekly.
+* We have discoverd the by-hand process is tedious and error-prone.
+* We can stage multiple pull requests in a testing branch so we can batch-up testing.
+* We can automatically land the result so merged pull requests show up as merged in github infrastructure.
 
 We need help with automating the process:
-* Add the ability to batch multiple pull requests
-* Add automated testing that's context specific (for example, run igor over man pages)
-* Add build/install tests that test boot the resulting image
-* Integrate CI we currently do post-commit so we can do it before for these changes.
+
+* Add automated testing that's context specific (for example, run igor over man pages).
+* Add build/install tests that test boot the resulting image.
+* Automate common tasks, like man page corrections, into staging process.
+* Add simple smoke testing for the staging branch for tier 1 architectures.
+* Investigate optionally integrating Jenkins testing to scale-up the size of changes we can accept.
+* Integrate with Bugzilla problem reports and Phabricator reviews.
+* Improve the submitter experience on github by automating common feedback to mistakes in the pull requests.
+* Create checklists for submitters to reduce errors.
+* Create better reporting about pull requests, especially the frequent contributors of good pull requests.
 
 We are coordinating on FreeBSD's Discord in the #github-hacking channel.
+Join us there to pitch in, or just chat about the project.
 
-Once we have things fine-tuned, we will be looking to expand this by doing publicity to steer contributors to at least the base system to GitHub.
-We need more developers looking at the FreeBSD GitHub pull requests
+Once things are fine-tuned, we want to publicity to steer contributors, at least the base system, to GitHub pull requests.
+We need more developers looking at the FreeBSD GitHub pull requests.
 We will also need more developers to review and land pull requests once it is automated and the automation has matured.
 We sincerely hope that we can improve the FreeBSD contribution experience with this, as well as gain useful fixes from the community.