community,wg,code-quality: establish working group code-quality

[dhiller]

What this PR does / why we need it:

Create wg charter and add sigs.yaml entry for wg-code-quality.

Update sig-list.md to reflect changes.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #327

Special notes for your reviewer:

This PR needs to get rebased after #346 got in

[kubevirt-bot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[dhiller]

Pinging folks for awareness - @0xFelix @lyarwood @iholder101 @EdDev @fossedihelm @enp0s3 @jcanocan @xpivarc @nunnatsa @ormergi

All, feel free to nominate yourself for a wg chair if you so desire by adding a suggestion with your github handle to the wg charter document.

[dankenigsberg]

(partial review)

[EdDev]

Thank you @dhiller for pushing this forward.
This is basically formalizing an ongoing active effort, allowing us to centralize, prioritize and learn how to make out code base cleaner/better.

[EdDev]

I think the deliverables should be the result of the scope points (objectives in the current naming), more or less.

I like the general wording of the device-manager WG:

The WG will coordinate the delivery of KEPs and their implementations by the participating SIGs. Interim artifacts will include documents capturing use cases, requirements, and designs; however, all of those will eventually result in KEPs and code owned by SIGs.

We could re-word it a bit to fit better to our naming (or lack of it) and scope:

The WG will coordinate the prioritization and delivery of design-proposals, documentation, implementations and other content that aims to improve the code quality of the project.

[EdDev]

Regarding the the chair and roles in general assignment, it will be useful to have a ref or and explanation (and example?) of what that means. Then it will be clearer to members what they need to do and estimate the needed investment.

I think we need a minimum of 2 chairs, preferable 3.
I am not really clear on how a nomination is done when a WG is created, it is a bit odd.
In any case, given my high interest in this WG success and my assumptions on what the role requires, please consider me as one of the chairs.

[dhiller]

Thank you @dhiller for pushing this forward. This is basically formalizing an ongoing active effort, allowing us to centralize, prioritize and learn how to make out code base cleaner/better.

@EdDev thanks for the review - I've changed wording accordingly, hope that this conveys better what we want to achieve.

Also I've updated with the new links to the meeting room, and added a paragraph for disbanding. This I've left vague intentionally.

One note though: this WG IMHO is about creating the process (which is kind of a meta activity) that will serve as a vehicle for continuous improvement. I think that we can iterate on that process, the docmentation and the automation continuously, so therefore the WG might disband after a certain "good enough" set of processes and documentation is in place.

[dhiller]

/hold to wait for rebase after #346 merged

[EdDev]

One note though: this WG IMHO is about creating the process (which is kind of a meta activity) that will serve as a vehicle for continuous improvement. I think that we can iterate on that process, the docmentation and the automation continuously, so therefore the WG might disband after a certain "good enough" set of processes and documentation is in place.

The term "process" is a bit to vague to me.
I would expect the WG to facilitate and manage the quality effort until enough tooling, documentation, code structure, reviewer and maintainer awareness is achieved. Once the code quality reached a reasonable state, the WG can be dismissed.

My remaining comments is all about this "process" I guess.
It is not a stopper though, we can and probably should sync on the expectation in the next WG meeting.
Per initial discussions we can keep on updating the charter to reflect what we learn and where we aim to go with this.

[EdDev]

work on processes

I am unsure if this is clear enough to keep it in the text.

As I see it, the WG should work on providing the means to improve the quality until a point where it is well integrated in the projects. The points above hints what we expect to have in the end.

I do not think it is limited to creating processes, it is there to facilitate the effort to create content, refactor code, etc. As it is already mentioned in the points above, I think this sentence is redundant.

[dhiller]

I have changed the In Scope section by changing the last sentence to what you pointed out before, which IMHO brings it down into an actionable goal. WDYT?

[EdDev]

For me, line 14 is summarizing this and describe why the WG is needed.
The long-term goal here, which mentions a processes, is not very clear to me.
I would expect the WG to have artifacts from which the quality will be improved and sustained over time.

This may be partially achieved through processes, but I am unsure if that is the "solution" or how it will look-like.

[dhiller]

Agree - see above comment.

[EdDev]

I guess I do not see this inter-SIG process in my mind and therefore have hard time to understand and agree on it being a goal. I feel this section is redundant as everything is described in the next section.

However, this is a small part compared to all this charter content, so I should not get stuck on it.
We can raise it later and adjust per need.

[dhiller]

One note though: this WG IMHO is about creating the process (which is kind of a meta activity) that will serve as a vehicle for continuous improvement. I think that we can iterate on that process, the docmentation and the automation continuously, so therefore the WG might disband after a certain "good enough" set of processes and documentation is in place.

The term "process" is a bit to vague to me. I would expect the WG to facilitate and manage the quality effort until enough tooling, documentation, code structure, reviewer and maintainer awareness is achieved.

That last sentence is a good one, I will add that to the charter if you don't mind.

Once the code quality reached a reasonable state, the WG can be dismissed.

I disagree with that the WG should disband after the code quality has reached a reasonable state. I think that it should disband after the above described facilitation and management is complete - meaning that tooling, docs etc. are in effect in order to not let the quality deteriorate below a certain lower boundary.

[dhiller]

@EdDev I've updated the charter - maybe that is good enough for a start? What do others think?

[dhiller]

I did a final polish, hope that's good enough for now - @orelmisan @lyarwood @EdDev @iholder101 PTAL again.

Thanks all for your input!

@aburdenthehand this should be nearing the approval phase.

[orelmisan]

Thank you @dhiller!

[iholder101]

Thanks a lot @dhiller!!

/lgtm

[iholder101]

nit: observability? testing? documentation?
which other SIGs do we currently have? :D

[aburdenthehand]

This makes sense for now, based on SIGs with current charters, although SIG-observability has an open PR so it would be worth including them.
Is the intention to update this as other SIGs are formalised?

[EdDev]

/hold to wait for rebase after #346 merged

It has been merged already.
/unhold

@aburdenthehand , can we merge this?

[lyarwood]

/lgtm

[aburdenthehand]

Good stuff. I have a few suggestions and an additional comment to Itamar's.

[aburdenthehand]

This makes sense for now, based on SIGs with current charters, although SIG-observability has an open PR so it would be worth including them.
Is the intention to update this as other SIGs are formalised?

[aburdenthehand]

/approve

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: aburdenthehand

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [aburdenthehand]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment