Project maintenance and planning

[rootwork]

@chipzoller @onweru When you get a chance, wanted your feedback on some project ideas. I can do PRs, but I don't want to invest in work before knowing if these seem like good ideas for Hugo Clarity.

1. Adding a label called "management", "project management", "planning", or something like that. For instance, for issues like this :) Alternatively we could use a section of Discussions (maybe create a planning category), or talk in private via email.
2. Cut releases. If I have a couple of layout files overridden in my local install, right now I have to track every time there's a commit that affects one of those files so I can pull in any new code manually. If there were periodic releases it would at least be easier to keep track of the version I'm on and what's been released since then. This isn't really something I can do with a PR; we just have to decide what version number to "start" on, and maybe establish some way to decide amongst ourselves when a new release is warranted (a certain length of time, a certain number of PRs, tagging PRs as "major" that generate a release when merged, etc.)
3. Add release notes and a changelog, assuming we do releases. This changelog generator can be used for automated release notes; I've used it myself and it's pretty easy.
4. Add more issue templates. Right now we only have a template for a bug report. Here's an example of the new issue page for another project I work on. You can see that you can have multiple types, as well as links -- for instance these days I'd probably direct people to Discussions rather than have a "support question" issue type. Also if you click through to one of the issue types you can see the new form-style templates that GitHub offers.
5. Add docs for contributing, (possibly) code of conduct, and the "good first issue" tag. Doing so gets you extra visibility in GitHub, for instance again from that project, you get the project "contribute" page. On having a code of conduct, we may feel we don't need one, although I've found it's helpful to have something pre-existing should there ever be behavior that leads to wanting to justify restricting/banning someone from project contributions.
6. Add sponsorship options? I don't know if this is something you'd want, but it's as simple as adding a FUNDING.yml file. You can offer tiers and/or rewards, like mentions in the readme. If that's not a path you want to go down, though, that's fine.

👍🏽 / 👎🏽 / ❓ on any of these?

[rootwork]

Meant to add on number 5 - one of the reasons I think a contributing document would be useful is the DCO test, which most people seem not to see (or know what to do about) when they first submit a PR.

[chipzoller]

1. If we're just discussing amongst ourselves and one of us is the creator of the discussion, I think the discussions (with a new section) might be best. It certainly doesn't hurt to have an additional label though. Not opposed to either/both.
2. Absolutely. We need to start doing releases with release notes. We talked about this a while back and all agreed (as I recall). Let's make it happen. I thought about this the other day. For the first release, do we want to just go with 0.1 or something else?
3. Also absolutely. A release must have a change log. We'll still probably want to manually curate release notes to make it easier for users to understand, from an outward usability perspective, what has happened. I really like how Antrea does this and would like to use that as a model.
4. Right, also agree. Need to adjust the current one as well. We can use the nice GitHub forms to do this. You can see what I've put together on the Kyverno repo here.
5. Also agree, let's do this.
6. I really don't know anything about sponsorships and what value this would bring so I'll have to read on that.

[onweru]

Gentlemen,

I agree with 👍🏼 2 ~ 5.

As far as the first (1) and last (6) points go, I'm not quite sure how they would work since we're not an organization. We're merely 3 guys plus other individuals who volunteer to work on an open source theme. That said, I get the sense that the first point is more approachable.

[rootwork]

OK, I'll work on PRs for 3-5, and see if there are any good examples of setting up a planning section of discussions for item 1.

For item 6, I don't know what funding would look like for a group of individuals; maybe that's too much to try to navigate.

On 2: I think it might depend on how "complete" you think the theme is @chipzoller. Is it what you originally envisioned, and now we're just adding new features? Then that sounds like 1.0.0 (at least). But if there are still big parts left to do from your original plan, then yes I'd say 0.x.0, and I guess making x anything other than 1 would probably be confusing. Then again, we all use Hugo which has been around for 9 years and still doesn't have a 1.x release, so... 🤷🏽

[rootwork]

For item 1, I've created a new category in discussions, Planning. There's no way to restrict participants, so anyone will be able to post and comment, but I think that's fine. We can always recategorize posts that come in there.