Issue Template Forms

[moritz-t-w]

There will likely be a lot of similar issues submitted to this repo, which is why I think it's important to organize them.
For the issue forms to work, the following labels need to exist:

• enhancement
• bindings
• output-formats

[holzensp]

I love what you're doing here. Don't let me slow you down, but I thought I'd drop a comment.

[holzensp]

It's fine to postpone, because you might be able to iterate faster without, but adding a template for this (and start this with amends "path/to/template/maybe/even/package/on/pkl-pantry") would give you the full Pkl experience ;)

You can also start by just putting type annotations in this file.

[moritz-t-w]

I was thinking about doing something like that but then I decided to just write the yml assisted by the existing template and basing the pkl on that, since it's not gonna be changed a lot and I didn't wanna bury myself in a rabbithole.
I'm not gonna go that deep atm but I bet as this gets more popular someone is gonna make a template that can then be used here.
Really seeing the use-cases of this language tho :D

[moritz-t-w]

I will write a template tho, where should I put that? I don't think it makes sense to put it in the ISSUE_TEMPLATE folder or one might confuse it with an actual issue template that didn't get rendered by accident. What do you think?

[holzensp]

In a very general sense; you can publish packages anywhere you like (that's just FYI for whatever else you might be looking to create templates for). All repositories maintained by the core Pkl team should really only be use packages in those repositories. This could be an excellent contribution to pkl-pantry. It's worth having a think about naming. I'm hesitant to suggest com.github as a package name, because that would suggest an authoritative source, but maybe com.github.contrib? (cc @bioball).

[moritz-t-w]

I was gonna write just a template for this specific usecase, not a completely generalized one. This would just include the "GENERATED" message and shared attributes between similar templates. Obviously that's not really necessary, but I wanted to try out some of the features of pkl, without writing a complete implementation of github's issue form standard.

[bioball]

Re: package name: I think com.github is entirely reasonable, as long as the templates simply represent a schema in the target domain.

Maybe the name should be more narrowly scoped, though? How about we call this com.github.issueTemplate? There's also GitHub Actions, which we probably don't want to group together with this.

[moritz-t-w]

I’d keep it local and remove the amends before commit

@holzensp what did you mean by this?

[holzensp]

^^ that as assuming you would amends "path/to/template/maybe/even/package/on/pkl-pantry"

Considering all your templates will have a name: String, description: String, title: String, Labels: Listing<SomeMeaningfulEnum>, body: Listing<BodyPart>, I would consider rolling a template for that.

If you follow the above advice about multi-file; the template would simply produce zero output files, so you can still evaluate *.pkl without issue. Keeping the template in this directory, instead of publishing it to pkl-pantry also communicates "this isn't a general implementation of the GitHub Issues API, it's just something used here."

[moritz-t-w]

"this isn't a general implementation of the GitHub Issues API, it's just something used here."

Exactly. If there is enough demand, someone is gonna make a full suite of GitHub scoped templates, I'll leave that to them and use a simple template for this use case.

[moritz-t-w]

So my question remains, where should I put the template file?

[moritz-t-w]

Is there a plan for proposals of changes to the syntax or should I also just make a template for that?

[moritz-t-w]

I just saw that I didn't adhere to the commit message guidelines. I'm gonna edit some commit messages.

[moritz-t-w]

I was gonna do bug report and feature request forms but then I thought, it should probably be separated between cli, standard library, etc.? Can someone give me a list of templates that I should make?
Currently there's:

• Language Bindings Request - Request for Pkl bindings for a programming language
• Output Format Request - Request for a output format to be added to Pkl

[holzensp]

^^ that as assuming you would amends "path/to/template/maybe/even/package/on/pkl-pantry"

Considering all your templates will have a name: String, description: String, title: String, Labels: Listing<SomeMeaningfulEnum>, body: Listing<BodyPart>, I would consider rolling a template for that.

If you follow the above advice about multi-file; the template would simply produce zero output files, so you can still evaluate *.pkl without issue. Keeping the template in this directory, instead of publishing it to pkl-pantry also communicates "this isn't a general implementation of the GitHub Issues API, it's just something used here."

[moritz-t-w]

Is there a plan for proposals of changes to the syntax or should I also just make a template for that?

@holzensp

[moritz-t-w]

@holzensp
#140 (comment)