Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue Template Forms #140

Draft
wants to merge 7 commits into
base: main
Choose a base branch
from
Draft

Issue Template Forms #140

wants to merge 7 commits into from

Conversation

moritztim
Copy link

@moritztim moritztim commented Feb 13, 2024

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

moritztim

This comment was marked as resolved.

Copy link
Contributor

@holzensp holzensp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@@ -0,0 +1,69 @@
name = "Language Bindings Request"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@holzensp what did you mean by this?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

^^ 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."

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@moritztim
Copy link
Author

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

@moritztim
Copy link
Author

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

@moritztim
Copy link
Author

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

.githooks/pre-commit Show resolved Hide resolved
.githooks/pre-commit Outdated Show resolved Hide resolved
@@ -0,0 +1,69 @@
name = "Language Bindings Request"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

^^ 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]>
@moritztim
Copy link
Author

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

@holzensp

@moritztim
Copy link
Author

@holzensp
#140 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants