This is a read-only snapshot of the ComputerCraft forums, taken in April 2020.
oeed's profile picture

RFC: ComputerCraft/CraftOS Centralised Standards Repo

Started by oeed, 11 January 2016 - 09:13 AM
oeed #1
Posted 11 January 2016 - 10:13 AM
With CraftOS 2.0 getting closer, which will certainly introduce countless more situations where standards will be useful, I thought it'd be useful to have a centralised place for standards. Earlier today I encountered issues with the possibility of one file extension being given multiples MIMEs (which almost defeats the purpose), so this seems like a good solution.

I called this an RFC because, while it's not actually proposing a code standard, if this is going to be effective it's imperative that everyone agrees on how they're proposed and defined.

Proposal

Essentially there is a GitHub repo, that explains all of this is greater detail (please read the README!!!). In short, when someone creates an RFC they write up a Markdown file and create a pull request on that repo. When they do that they will also need to create a topic in General with a link to the pull request so people are aware of the proposal.

Any issues or suggestions will then be discussed and proposed using the pull request (not the forum topic) and the markdown file edited until everyone is happy, at which point it will be merged by a repo collaborator (probably myself, Lyqyd and Dan if they're up for it, the fewer people the better to be honest). Once it is merged it is 'officially accepted'.

I'm unsure of whether there should be any defined format for the RFCs or not. I'm also not really sure what should happen if a standard needs to be updated. I guess you'd just make a pull request with the changes, but how do you maintain versions? (furthermore, is important to maintain versions?)


This is obviously just a proposal, so I'd be interested to see what you think. The main rationale with not having it on the forums is the ability for anyone to edit and to maintain changes easier. Additionally, the reason why I suggest keeping all discussion on the pull request is that there will naturally be some discussion there anyway, so it seems logical to avoid separating it out.

Another issue raised by Quartz101's pull request is what makes something in need/worthy of standardisation. Is there anything wrong with standardising everything? However, making a format that is only used by 1 program a standard seems overkill.
Edited on 11 January 2016 - 10:11 AM
Quartz101 #2
Posted 11 January 2016 - 10:39 AM
I submitted a pull request.
Lyqyd #3
Posted 11 January 2016 - 05:15 PM
I'd be up for it.

I'd suggest that a better procedure would be to have an initial draft posted to the forums, where it can be commented on and viewed by a larger number of interested people, and then integrate the feedback received from the forum post into the draft that would then be submitted to the repo. Any further discussion can happen on the pull request at that time, prior to acceptance.
oeed #4
Posted 11 January 2016 - 11:30 PM
I'd be up for it.

I'd suggest that a better procedure would be to have an initial draft posted to the forums, where it can be commented on and viewed by a larger number of interested people, and then integrate the feedback received from the forum post into the draft that would then be submitted to the repo. Any further discussion can happen on the pull request at that time, prior to acceptance.

That's a good point, although the issue I see with that is it means people would have to write a version specifically for the forums as it doesn't support markdown.
Lyqyd #5
Posted 12 January 2016 - 01:45 AM
Markdown is generally pretty readable even when it's not being formatted. The only potential issue might be tabular data, and that wouldn't be too hard to space out a bit into a forum-readable format, even if it then needed to be in a code block to preserve the spacing. I don't see any other major issues that would make markdown unreadable when posted to the forum.
MrObsidy #6
Posted 18 January 2016 - 07:12 AM
Another thing that bugs me is that many people don't take already Existing programs, but instead create a program with the exact same functuality but another branding. The result is non-compativle systems. So I think that we (the community) set standards also in this area, e.g. Lyqyd's Packman as the standard package manager or LyqydNet or InZernet as the Standard Internet API or so.
SnappGamez #7
Posted 07 June 2016 - 03:19 AM
Another thing that bugs me is that many people don't take already Existing programs, but instead create a program with the exact same functuality but another branding. The result is non-compativle systems. So I think that we (the community) set standards also in this area, e.g. Lyqyd's Packman as the standard package manager or LyqydNet or InZernet as the Standard Internet API or so.
You have a point, but here's another: Linux has multiple different package managers and yet it's going fine. As for internet apis, that's pretty much a given.

As for this however…
I'm unsure of whether there should be any defined format for the RFCs or not. I'm also not really sure what should happen if a standard needs to be updated. I guess you'd just make a pull request with the changes, but how do you maintain versions? (furthermore, is important to maintain versions?)
1) There should probably be a defined format for the RFCs to improve readability.
2) It should go like so:
Step 1. Someone makes a pull request with the suggested changes.
Step 2. Everyone decides (probably through a poll) if the changes should be put in.
Step 3. If the changes are put in, the pull request will be accepted and the old version of the file will be copied and put in a "previous version" folder or something. Maybe append a -v# to
the end of every file with the # being replaced with the version number of the standard.

Sound good?
thecrimulo #8
Posted 04 July 2016 - 12:03 AM
I like the MIME-like types, but I don't want to put an extension to my files while it runs without ./ or .lua
I'll try to come up with more types, i think i know how it could be done :)/>