generator-yyip/generators/app/templates/yip-template.md

yEarn Improvement Proposal generator based on Yeoman

---
yip: <%- yipNumberAssigned ? yipNumber : '<to be assigned>' %>
title: <YIP title>
author: <%= yipAuthor %> (@<%= yipAuthorGithubUsername %>)
discussions-to: <reate a new thread on https://gov.yearn.finance/ and drop the link here>
status: <%= yipStatus %>
type: <%= yipType %>
<% if (yipType == 'Standards Track') { %>category: <%= yipCategory %>
<%}-%>
created: <%= yipDateCreated %>
requires (*optional): <YIP number(s)>
implementation (*optional): <YIP number(s)>
---

<!-- %% START OF YIP BODY %% -->
<!--You can leave these HTML comments in your merged YIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new YIPs. Note that an YIP number will be assigned by an editor. When opening a pull request to submit your YIP, please use an abbreviated title in the filename, `yip-draft_title_abbrev.md`. The title should be 44 characters or less.-->

This is the suggested template for new YIPs.

Note that an YIP number will be assigned by an editor. When opening a pull request to submit your YIP, please use an abbreviated title in the filename, `yip-draft_title_abbrev.md`.

The title should be 44 characters or less.

## Simple Summary

<!--"If you can't explain it simply, you don't understand it well enough." Simply describe the outcome the proposed changes intends to achieve. This should be non-technical and accessible to a casual community member.-->

"If you can't explain it simply, you don't understand it well enough." Simply describe the outcome the proposed change intends to achieve. This should be non-technical and accessible to a casual community member.

## Abstract

<!--A short (~200 word) description of the proposed change, the abstract should clearly describe the proposed change. This is what *will* be done if the YIP is implemented, not *why* it should be done or *how* it will be done. If the YIP proposes deploying a new contract, write, "we propose to deploy a new contract that will do x".-->

A short (~200 word) description of the proposed change, the abstract should clearly describe the proposed change. This is what _will_ be done if the YIP is implemented, not _why_ it should be done or _how_ it will be done. If the YIP proposes deploying a new contract, write, "we propose to deploy a new contract that will do x".

## Motivation

<!--This is the problem statement. This is the *why* of the YIP. It should clearly explain *why* the current state of the protocol is inadequate.  It is critical that you explain *why* the change is needed, if the YIP proposes changing how something is calculated, you must address *why* the current calculation is innaccurate or wrong. This is not the place to describe how the YIP will address the issue!-->

This is the problem statement. This is the _why_ of the YIP. It should clearly explain _why_ the current state of the protocol is inadequate. It is critical that you explain _why_ the change is needed, if the YIP proposes changing how something is calculated, you must address _why_ the current calculation is innaccurate or wrong. This is not the place to describe how the YIP will address the issue!

## Specification

<!--The specification should describe the syntax and semantics of any new feature, there are five sections
1. Overview
2. Rationale
3. Technical Specification
4. Test Cases
5. Configurable Values
-->

### Overview

<!--This is a high level overview of *how* the YIP will solve the problem. The overview should clearly describe how the new feature will be implemented.-->

This is a high level overview of _how_ the YIP will solve the problem. The overview should clearly describe how the new feature will be implemented.

### Rationale

<!--This is where you explain the reasoning behind how you propose to solve the problem. Why did you propose to implement the change in this way, what were the considerations and trade-offs. The rationale fleshes out what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->

This is where you explain the reasoning behind how you propose to solve the problem. Why did you propose to implement the change in this way, what were the considerations and trade-offs. The rationale fleshes out what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.

### Technical Specification

<!--The technical specification should outline the public API of the changes proposed. That is, changes to any of the interfaces yEarn Finance currently exposes or the creations of new ones.-->

The technical specification should outline the public API of the changes proposed. That is, changes to any of the interfaces yEarn Finance currently exposes or the creations of new ones.

### Test Cases

<!--Test cases for an implementation are mandatory for YIPs but can be included with the implementation..-->

Test cases for an implementation are mandatory for YIPs but can be included with the implementation.

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

<!--%% END OF YIP FILE  %% -->