Is this project still maintained?

[zhimsel]

There hasn't been a PR merged in a few months, and there hasn't been a release in a year and a half.

[pascal-hofmann]

CC @khos2ow, @metmajer

Do you need help with maintaining terraform-docs?

[metmajer]

Hi @zhimsel @pascal-hofmann I have just reached out to @khos2ow to understand current maintenance levels. We will get back to you!

[khos2ow]

Absolutely! Unfortunately I've been very busy in the past several months. I'll try to pick up the slack soon. But in the meantime I can review/approve PRs if there are any.

[tbugfinder]

@khos2ow
Please add maintainers so that this project is not getting "orphaned".

[tbugfinder]

Is a fork preferred ?

[zhimsel]

I mean, not really, since this project has many downstream repos/binaries/packages/etc.

[brsoren]

I know this is actively getting PRs but can we get a release of new binaries so that people using this in github actions etc arent running with the vulns that were recently fixed?

[tbugfinder]

@khos2ow @metmajer

It really looks like you'd need help on this project.
Call for maintainers?

[rquadling]

Hi. I'm new to Go, but a LONG time Terraform user. I'm happy to help with what I can. Anyone interested can reach out to me and we can see where we go from there.

[brittandeyoung]

I would be happy to help maintain the project. Please reach out to me if that is possible. I currently have a very simple pr raised that is needed to to enable generating docs for any module containing the new provider defined functions. Currently it will crash the app.

@khos2ow

[khos2ow]

@brittandeyoung @pascal-hofmann I invited you to the org. Please check your inboxes. I'll try to also pick up some of the slacks. But please feel free to keep the light on and ping me if you need me on something urgent

[khos2ow]

now?

[brittandeyoung]

looks like I am now able to manage issues and close pull requests.
I am NOT able to merge a pull request or approve running workflows. is this expected?

[khos2ow]

No, you should be able to do both. Give me a minute.

[khos2ow]

Try now?

[brittandeyoung]

I have permission now! thank you. When it comes to guidelines and making new releases. Is there any documentation on existing processes?

[brittandeyoung]

@pascal-hofmann We should find a way to communicate with each other for:

1. planning on what should be worked on first/ roadmap
2. planning / co-ordinating releases

Would the slack channel be a good place to do this? Maybe we keep it all in github projects?

[pascal-hofmann]

Github is good for non-urgent things. I guess slack makes sense for things where we need to coordinate closer.

[brittandeyoung]

@khos2ow From the workflows it looks like triggering a new release is to simply create the release with the correct semantic version. Does the release information get auto populated from commits? Or is this manually set by the person creating the release?

[pascal-hofmann]

@khos2ow I'm also curious how this works. Can you describe what needs to be done in order to create a new release?

[pascal-hofmann]

I saw that there is a Makefile with targets in .github/scripts/, but how is the "Notable changes" section populated?

[rquadling]

One of the external modules this project needs is the terraform-config-inspect. Sadly, that dependency is not going to get updates that allow improvements in terraform-docs.

I have my fork, with the improvements that allow validation messages to be available and so can be reported by terraform-docs (See #675).

If my fork was pulled into https://github.com/terraform-docs/terraform-config-inspect, then the dependency would be under this projects control.

I'm NOT a professional Go developer, but I am learning to code in Go from a working project. I'm happy to help with whatever is deemed a good pattern.

From what I can tell, there's a LOT of things that could be reported upon but are not accessible easily. I am aware that some of the changes Hashicorp may be making in future versions of Terraform will effectively make the terraform-config-inspect library, as it currently stands, not capable of reading the new elements. For example, currently, the validation error messages must be a literal string. Easy to process. But if/when that becomes a parsed string with embedded variables, use of format() or other related functions, reporting of that will now be more difficult ... would we want to be including "code" in "documentation"?

Happy to help/contribute as best as I can, but would like someone who knows what they are doing to be able to correct anything I do as I'm still learning Go.