Editing the RFC issue template

[lauranolling]

Hello everyone,

As you might have seen, I have added a "Request For Comments (RFC)" template, as an Issue template. The RFC structure is from the Energy Track and Trace Github.

I have created another template, a Feature Request, for specific software implementation suggestions, when someone starts working on a specific feature. However, I find that the RFC format could be used for the exact same purpose.

I think the RFC is broader, and can be used for several purposes, even non-development suggestions. A nice aspect of RFCs is that it transitions to different "statuses", up until we (the community) make a decision, and it supersedes to a "Decision Record", or ground truth for the given topic, when moving forward.

Given my thoughts above, I would like some inputs to the following:

- Should there be two separate templates, one specifically for software feature requests (the Feature Request), and one broader, and less strict in format (the RFC)?

- Or could the RFC work as a "standard template" for any topics that we need to make decisions for?

If we agree on moving forward with the RFC, I will work on creating it in the same format as the other issue templates. 🙂

[wisbech]

Hi Laura,

Interesting proposition - what is an RFC in the first place, it is a Request For Comment - meaning we would appreciate your input and if the input and change qualifies we will adopt the change and if we are really troubled by the new insights we form a new RFC based upon that and supercede that RFC with the new and improved RFC.

I agree that the key feature is the status of the RFC, we can simply find a ground truth in the working group by reading what is active and come with a proposalthat changes this state/status.

The ADR is what comes after the RFC - whereas the RFC clarifies the problem space - the ADR becomes a choice record primarily by involved architects that has freedom of choice in implementation method. There are many such choices, ones with big implications database types, data-structures, API definitions etc. Other ADR's with small but defining treats like formatting etc, those that cannot be automated should be described and put in the ADR, a great example is the choice between camelCase and snake_case as naming convention, it is a choice but the choice should be consistent.

So back to your question let us make an ADR issue-template. That goes in a specific ADR folder, just as with the RFC.

Please note that project origin only has a doc/concept folder that tells the story of why - not a request for comment. We can always say it is open to PR's 👍

[lauranolling]

Thanks for your inputs @wisbech - Now the distinction is clear to me. I started wondering, because the structure in the RFC and feature request is quite similar in some ways, but obviously the purposes are quite different.

Regarding the ADRs - I will work on creating a template here. Based on your comment above, I would like some inputs:

• Should we create two different templates, depending on the type of decision (camel/snake)?
• Or should we create one form, but in a way that fits several "decision sizes"?

[wisbech]

I would personally go with two different templates one for RFC and one for ADR's, most developers / architects and the like communicates in code and do not write extensive long stories about it so a template that addresses the bare minimum input would be fitting. We can always make the template more extensive if necessary.

So in conclusion I would say in regard to purpose

• RFC - the story/narrative of the project and the pre-assesment of problem space as it is percieved / agreed upon from a business / solution perspective. In short - the why.
• ADR - a decision record of implementation specific decisions in order to deliver on the story/narrative. In short the how.

I hope this makes sense :-)

[lauranolling]

It makes sense - I have one for RFCs, but will also make one for ADRs. The question regarding ADRs was more if the structure of the ADR template should differ, depending on how big the decision made is. 🙂

[wisbech]

It makes sense - I have one for RFCs, but will also make one for ADRs. The question regarding ADRs was more if the structure of the ADR template should differ, depending on how big the decision made is. 🙂

I believe that we might be able to make a field that rates importance - but that introduces that all ADR's should be weighted alike, I do not believe that will end well. Maybe just a simple form that adresses:

• The decision
• The why
• The how
• The author / decision maker

[lauranolling]

Thanks for the inputs @wisbech! 🙂

[AndreAlnor]

@wisbech Did you guys end up with an open RCF and ADR template? If so could you share the location?