I consider this to be a suitable middle ground.
blackwolfsa’s naming proposal preserves at-a-glance determination of each RFC. Being able to discover the status and focus quickly by RFC name would be helpful to me and possibly others, particularly as creative input grows.
I agree with fox that maintaining changing links would become an unmanageable problem, and that broken references would make it more difficult for neophytes and casual users to become more involved.
@blackwolfsa OK-- so the filenames in this case would be decoupled from the actual RFC name/URL from the get-go, and the RFC name is what’s determined only by what’s on the page, right? Then we keep the links, use the new schema for naming moving forward, and just update the name in the documents?
I can get behind that. I’ll consult the docs and update the TIP, and will ping here once done. Let me know if my writeup matches what you were saying.
yeah there are 2 important things I want the names to say, status and domain.
For status we have:
Proposal
Accepted
Active
Deprecated
Rejected
And for Domains:
Core or MinoTari or L1
Ootle
Tempaltes
Application or individual names aka TariUniverseor TariNode etc
So we can
p-RFC-MT-0123 or p-TIP-MT-0123
a-RFC-MT-0123 or a-TIP-MT-0123
RFC-MT-0123 or TIP-MT-0123
d-RFC-MT-0123 or d-TIP-MT-0123
r-RFC-MT-0123 or r-TIP-MT-0123
for the names.
We should still do the headers
Thanks for clarifying, @blackwolfsa . I have been meaning to push an update to the proposal but have managed to get swamped with other work. I still expect to have it to you this week.
Dont worry,
I need to continue the review process of the existing RFCS anyway. I want to do this in two steps. One review fixing just purely details, then we can have a next one fixing the names etc
Thanks, @blackwolfsa . Here’s a revision for you to look at.
I like most of this, I do think we need to talk specifics about the types and statuses.
On types,
RFC’s is too broad, and L1 and L2 have completely different architectures.
I would propose the following:
MinoTari
Otoole
Process (I think best practice and product direction can go under this as they wont have a lot)
On statuses, I think there are too many; some of them can be combined
Draft → this can stay as a PR while its being worked on
Under Review → is fine I think,
Accepted → agreed
Then we need a rejected so that we have merged list of rejected TIPs with the reason they are rejected thats is displayed on the website, not just PR.
I dont think we need Deferred or Provisional. Accepted is the same as provisional? If it requires more work, it should stay in under review as it requires prerequisite work to be accepted. With a blocker on it.
Obsolete and Replaces is the same, as deprecated, we can chose one, and stick with it. I vote for depricated as it kinda encompases both words, and replaces as the short acronum R which will clash with rejected.
Needs Revision, seems like an unnecessary step, if a PR requires a doc update in the rfc page, we can make the merge of that PR dependant on an approvaed PR to the rfc repo.
@blackwolfsa I’ve pushed a new change set. Here’s what’s changed:
RFC’s is too broad, and L1 and L2 have completely different architectures.
This is what the SUB part of the naming schema is for. I’m suggesting a follow-up TIP be written to define any SUB portion for a particular type. It could contain MinoTari, Ootle, Wallet or whatever you like.
I’ve kept ‘Needs Revision’. I think this has some critical utility for when we discover an RFC is out of date but we don’t have time to fix it up in that moment-- so folks can quickly see that an RFC may not reflect reality.
I suspect this would come in handy in your current auditing work-- most RFCs might get light and quick updates, but some others might be more involved and it would be helpful to portion them out later rather than try to do everything at once.
Looking good, left a review
Thanks! Let me know if this recent push works for you.
as it stands, I am happy
Thanks, @blackwolfsa 
I’ve pushed one more change – updating SUMMARY to show the current name. Per the process so far, can we merge the PR now, or do you need me to squash existing commits down first?
Merged, I will rebase and update my other pr.
and then continue on the other rfcs
I am going to ask the community to help here, but we need to review and fix the existing rfcs in terms of content. I am slowly going through them. But would reviews on that for stuff I miss or can improve on.
we should update the template md file as well.
But something I was wondering when looking at the files. And thats the change log, I am unsure if we really want to include that high a level of detail there? We have the git history already containing that
I’m game for dropping it-- if we can link each page to its file in the Git repository, making it easy to look up said changes. I think there should be some way to do that in the theme.
we can perhaps have a shortend version? Almost like the current rfcs. The downside is the git pages is not too easy to read
I’m not sure it’s that much shorter in practice. We can do that if you like, though. I think that having a page link to the file history on GitHub would be workable for this section, though, or else just using one of those ‘visit this file in GitHub’ buttons in the theme chrome, if we’re willing to be less direct.
I am not feeling particularly strong on either options? I am also open to any new ones.
I am going to keep trying to push small updates the rfcs in sections.
@blackwolfsa I started looking into adding GitHub links into the themes but saw that it takes a plugin to do that sort of thing and we’re way out of date. I revived an old branch I was fooling around with to upgrade the dependencies a few weeks back and finished it.