74 lines
1.8 KiB
Markdown
74 lines
1.8 KiB
Markdown
---
|
|
name: Feature Request
|
|
about: Want us to add any features to Jekyll?
|
|
title: 'feat: '
|
|
labels: feature
|
|
assignees: ''
|
|
|
|
---
|
|
|
|
<!--
|
|
Hi! Thanks for considering to file a feature request with Jekyll. Please take the time to
|
|
answer the basic questions. Please try to be as detailed as possible.
|
|
|
|
Thanks!
|
|
-->
|
|
|
|
## Summary
|
|
|
|
<!--
|
|
A one-paragraph explanation of the feature.
|
|
-->
|
|
|
|
## Motivation
|
|
|
|
<!--
|
|
Why do you want to see this feature in Jekyll? What makes you sure that it should not be
|
|
implemented at the plugin level, but in Jekyll core? What use cases does it support?
|
|
|
|
NOTE: Please be mindful of the Jekyll philosophy (https://jekyllrb.com/philosophy/),
|
|
particularily Section 5. Think about if 90% of the users would benefit from your
|
|
feature request, and whether your feature would be better off in a plugin.
|
|
-->
|
|
|
|
## Guide-level explanation
|
|
|
|
<!--
|
|
Explain the proposal as if it was already included in the project and you
|
|
were teaching it to another programmer. That generally means:
|
|
|
|
- Introducing new named concepts.
|
|
- Explaining the feature largely in terms of examples.
|
|
- If applicable, provide sample error messages, deprecation warnings, or
|
|
migration guidance.
|
|
|
|
If this is a small feature, you may omit this section.
|
|
-->
|
|
|
|
## Reference-level explanation
|
|
|
|
<!--
|
|
This is the technical portion of the feature request. Explain the design in
|
|
sufficient detail that:
|
|
|
|
- Its interaction with other features is clear.
|
|
- It is reasonably clear how the feature would be implemented.
|
|
- Corner cases are dissected by example.
|
|
|
|
If you do not know how to answer this, you can omit it. No worries!
|
|
-->
|
|
|
|
## Drawbacks
|
|
|
|
<!--
|
|
Why should we *not* do this?
|
|
-->
|
|
|
|
## Unresolved Questions
|
|
|
|
<!--
|
|
What related issues do you consider out of scope for this feature that could be
|
|
addressed in the future independently of the solution that comes out of this
|
|
feature?
|
|
-->
|