improve: add clean coding standards copilot instructions

[juliusvonkohout]

To make sure that we get proper pull requests from GSOC students.

[juliusvonkohout]

/approve

[google-oss-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: juliusvonkohout

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [juliusvonkohout]

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

[Copilot]

Pull request overview

This pull request adds a new .github/copilot-instructions.md file to establish clean coding standards for GitHub Copilot-assisted development in the Kubeflow Dashboard repository. The guidelines emphasize scientific elegance, minimalism, and long expressive names over abbreviations, along with principles about testing, documentation, and development practices.

Changes:

• Created .github/copilot-instructions.md with coding standards including naming conventions, testing requirements, and development workflow guidance

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[christian-heusel]

To make sure that we get proper pull requests

Also is this the approach that we should take in this case? I'd argue that if the things the .github/copilot-instructions.md currently tries to fix are the problems that we're facing then we shouldn't accept those contributions anyways 😅

Also I think in the last community meeting the idea came up to establish a Kubeflow wide policy for AI usage, potentially something similar to https://www.kubernetes.dev/docs/guide/pull-requests/#ai-guidance.

I think that this especially makes sense given that the project seems to have a shortage of reviewers/maintainers rather than contributors 🤔

[thesuperzapper]

I am more concerned about not having an AI policy for the repo in the first place.

Adding this file implies that we will accept AI generated PR's , which I think needs to be qualified by a policy around users not raising generated PRs they have not reviewed first, and setting the expectation that users must understand ALL changes they are proposing as if they had written them themselves.

I am also not sure there is much value from a code perspective in these instructions, any "rule" we have for AI is a rule for human contributors too, and some of the listed rules here are not rules we enforce on humans.

/hold

[google-oss-prow]

New changes are detected. LGTM label has been removed.

[juliusvonkohout]

I am more concerned about not having an AI policy for the repo in the first place.

Adding this file implies that we will accept AI generated PR's , which I think needs to be qualified by a policy around users not raising generated PRs they have not reviewed first, and setting the expectation that users must understand ALL changes they are proposing as if they had written them themselves.

I am also not sure there is much value from a code perspective in these instructions, any "rule" we have for AI is a rule for human contributors too, and some of the listed rules here are not rules we enforce on humans.

/hold

So there is now some feedback on PRs from github copilot, to provide some base data of usefulness, even without the policy here.
Actually these rules seem quite useful too me to have some base standard for code quality and guide contibutors to commit readable and maintainable code.
I also added an AI policy as suggested above directly in the copilot instructions.