docs: merge HACKING.md into CONTRIBUTING.md, fewer files in root

[benhoyt]

This PR makes several changes to reduce the number of files in the root directory of the repo.

Most significantly, it moves the content of HACKING.md into CONTRIBUTING.md without changing any of it (except minor adjustments to the headings):

• Setting up a dev environment: moved straight across
• Testing: merged with "Tests"
• Maintaining the documentation: merged with "Documentation"
• Dependencies: moved to under "Pull requests"
• Dev tools: merged with "Setting up a dev environment"
• Releases: moved straight across
• Updating the Charmcraft profiles: moved to a top-level section

Within CONTRIBUTING.md:

• Moves "Coding style" up to a sub-section under "Pull requests"
• Removes the "Reviews" section; I actually did this by accident, but I don't think it pays for itself and should be removed (it's obvious)

In addition, the PR:

• Moves CODE_OF_CONDUCT.md into the .github dir (GitHub still shows a tab)
• Moves sbomber config files into .github
• Moves release.py into .github (I know we're going to replace it soon, but no harm in the meantime -- we run it with tox.ini anyway)
• Removes STYLE.md, as its content is now at https://github.com/canonical/charm-tech/tree/main/style

The only change I'm not sure about is how I'm referencing the new style guides in AGENTS.md. Will agents pick those up?

NOTE: I plan a follow-up PR to clean up CONTRIBUTING.md a bit, as I think there's a bit of duplicate content there now, and probably some things that can be removed or shortened.

Fixes #2487

[tromai]

Thanks for the PR.

I read through the changes, and cross-check with the details in the PR description. Everything looks great.

I have a small comment on which URL we should reference the style docs in AGENTS.md. I think raw.githubcontent.com works better, but happy to go with github.com from the charm-tech repo guide to be consistent.

EDIT: there is one thing I spot from CONTRIBUTING.md. I saw a mix of multi-line paragraph and one-line paragraph. I recall we made a decision to switch to one-line paragraph only (if I remember correctly). This could be part of the follow up PR too.

[tromai]

I also thought raw.githubusercontent.com links work better for agents.

But the instructions here say that AGENTS.md should point to https://github.com/canonical/charm-tech/blob/main/style/docs.md. I think we should keep it consistent and use the github.com links ?

[tonyandrewmeyer]

I feel that if it's something in a file that only an agent is meant to read, like here, then raw.githubusercontent.com is the better choice. If it's a file that a human or an agent might read (like CONTRIBUTING.md) then github.com is the better choice (and typically agents will figure it out, or, ideally, they're requesting Markdown and the server is configured properly to serve that instead, without having to change the path).

[benhoyt]

@tonyandrewmeyer Mind reviewing this one in the next couple of days?

[tonyandrewmeyer]

It seems odd to have the code of conduct in .github, given that it's not really GitHub specific in any way. I suppose that since it's now a pointer to a CoC somewhere else, I should think of this not as "the CoC" but "the GitHub pointer to the CoC" and justify it that way. I don't think it gains much to move it, but I'm not strongly opposed.

I'm not a fan of release.py in .github - in other PR discussions recently we talked about a scripts folder or similar, where this could live. However, James and I are meant to rework this system in the next couple of weeks, and based on our chat today I think almost everything will end up in charm-tech-code and workflow YAML files, so moving it now is fine.

+1 on moving the sbomber files. It's tempting to try to get rid of them instead (passing arguments to the tool rather than having a manifest file at all) but I'm happy to leave that for a different PR.

It does seem like there is a difference in the intended content in HACKING.md and CONTRIBUTING.md, but on the other hand I think the team agreed that they could merge, and almost all the other repos only have CONTRIBUTING.md, so I like the consistency. I've lightly reviewed this but mostly assumed that it's roughly the same content. Now that it's one file, a good follow up would be to see if it can be trimmed a bit, I think -- perhaps this would be good for Matt, since it's probably easiest to know what's really useful when you're coming with fresh eyes?

My only significant concern here is whether agents will still make use of the style guide. If we've validated that they (typically) will, then everything's good with me.

[tonyandrewmeyer]

Have you done any testing to validate that (at least for the common agents and models we use) this is essentially a no-op, or an improvement? I would like to be confident that the style is going to be picked up, because it feels like one of the few things AGENTS.md is still useful for. I'm particularly concerned that an agent might just ignore this file, or the directive in it, but would "see" the STYLE.md at the top level, so pick it up that way, which wouldn't be possible any more.

By doing this, I assume we're somewhat landing on an answer to an open question (issue) in the charm-tech repo about how we distribute the various Markdown files, and that answer is that they will live in that repo, and get references from the other repos. I'm ok with that solution, and I like the simplicity over something that validates that they remain in sync, but I think Harry and James were not completely convinced.

I think Harry's concern was injection can be done in a single place (the charm-tech repo) and then is immediately applied across all our repos. I feel like since there's a two-person review required there, and it's source control so we see history, we can subscribe to changes, and so on, it's an acceptable risk. The benefit is the same thing: we don't need to have a round of PRs in ~10 repos every time we update the style guide, or have to push some sort of release or tag.

I'm not sure I remember James's concerns exactly, but I think maybe it was more about the tools like YAML and Python files, so perhaps not relevant here.

[tonyandrewmeyer]

I feel that if it's something in a file that only an agent is meant to read, like here, then raw.githubusercontent.com is the better choice. If it's a file that a human or an agent might read (like CONTRIBUTING.md) then github.com is the better choice (and typically agents will figure it out, or, ideally, they're requesting Markdown and the server is configured properly to serve that instead, without having to change the path).

[tonyandrewmeyer]

Suggested change

	Then install `tox` with extensions, as well as a range of Python versions:
	Then install `tox` with the `tox-uv` extension:

[tonyandrewmeyer]

Do we need to include this? I think most Python devs would know or easily figure out that they could go find this information in pyproject.toml. This is somewhat true of the section above as well (just run tox lint and tox will sort it all out for you) but I lean slightly towards keeping that.

Suggested change

	## Building
	The build backend is [setuptools](https://pypi.org/project/setuptools/), and
	the build frontend is [build](https://pypi.org/project/build/).

[james-garner-canonical]

FWIW I'd go with CoC in the root over .github/.

Another cleanup opportunity would be migrating to a modern build backend, which would let us drop MANIFEST.in, but probably best as a separate PR.

[tonyandrewmeyer]

Another cleanup opportunity would be migrating to a modern build backend, which would let us drop MANIFEST.in, but probably best as a separate PR.

Oh, that was bad review on my part, I forgot to look at what was still there.

• I agree getting rid of MANIFEST.in is worthwhile, and that doing it in a follow-up is fine.
• I feel we should move test into ops with a src layout (this also solves other issues), but definitely in a different PR.
• Possibly CHANGES.md could be in docs/, although I do like docs/ being specifically what lands in the docs site.
• We should remove the old .claude/settings.json file.