Issue Template Forms #140
Issue Template Forms #140
Conversation
moritztim
force-pushed
the
issue-forms
branch
from
95b09f5 to
6234783
Compare
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
moritztim
force-pushed
the
issue-forms
branch
from
66ea059 to
30c0873
Compare
| @@ -0,0 +1,69 @@ | |||
| name = "Language Bindings Request" | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I’d keep it local and remove the
amendsbefore commit
@holzensp what did you mean by this?
There was a problem hiding this comment.
^^ 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."
There was a problem hiding this comment.
"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.
There was a problem hiding this comment.
So my question remains, where should I put the template file?
|
Is there a plan for proposals of changes to the syntax or should I also just make a template for that? |
|
I just saw that I didn't adhere to the commit message guidelines. I'm gonna edit some commit messages. |
Co-authored-by: Philip K.F. Hölzenspies <[email protected]>
Co-Authored-By: Philip K.F. Hölzenspies <[email protected]>
moritztim
force-pushed
the
issue-forms
branch
from
044e30a to
7f3560f
Compare
|
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?
|
| @@ -0,0 +1,69 @@ | |||
| name = "Language Bindings Request" | |||
There was a problem hiding this comment.
^^ 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."
Co-authored-by: Philip K.F. Hölzenspies <[email protected]>
|
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: