Discuss @ Discussions, then: discussion to pull requests to commit #21
Replies: 7 comments
-
|
I agree with you, we need to finish setting up a meta-standard for dealing with XLS standards. There should be a time limit for XLS draft standards to remain in draft mode. When they are either accepted by crossing the time limit or rejected by the community the issue is closed. If accepted a PR is made to merge the standard into the code-base with draft status removed. We also need a way to deprecate old standards. I propose old standards can be deprecated by opening an issue which just starts with deprecate: XLS-nn and causes the same sequence of events as above to happen, with a successful deprecation resulting in a simple deprecation notice being entered into the code for that standard. Time limit for all issues should be 3 months imho. Gives everyone lots of time to comment and integrate. Thoughts? |
Beta Was this translation helpful? Give feedback.
-
|
@thejohnfreeman I like the proposal to work with PR's. @codetsunami Maybe with a way to keep it open, eg. a certain reply / ... if things are awaiting other decisions / implementations. |
Beta Was this translation helpful? Give feedback.
-
This makes it sound like an issue that languishes under the radar long enough is automatically accepted. Is that what you meant?
What indicates a proposal is rejected by the community? I think proposals should be "rejected by default" and acceptance should be explicitly affirmative. The key problem here is that "the community" is a little nebulous. I don't know of a means right now to count stakeholders, much less poll them, especially in a way that is immune to gaming. I think we can look to other standards bodies, like what exists for Python or C++, for inspiration. In a bright future we might have a non-profit foundation or committee, staffed by volunteers, to discuss and craft the direction for XRPL with an open standards process. For now, I think whoever wants to lead this endeavor (maintainers of this repository?) should design a process, submit a PR documenting it in the README, and use that opportunity to take comments and make revisions. Then use that process to manage the other proposals, including amendments to the process. |
Beta Was this translation helpful? Give feedback.
-
A valid criticism. At risk of making these rules sound too laissez-faire for a standards body let me back up a little bit and provide some context for XLS. Prior to XLS, and arguably to some extent now, everyone working with or on the XRPL was just "doing their own thing." Proprietary blackbox interfaces, attempted but unannounced standards, quirks-mode defacto standards haphazardly built from old broken standards, you name it. The point of XLS, at least in my mind, is to provide a forum for everyone to come together and have a discussion about what external facing interfaces should be. If we make that discussion highly exclusive (like some other standards bodies) then we risk alienating the very developers, exchanges, etc. we want to bring to the table and thus defeat the purpose of the body. If we make the rules too loose we also defeat the purpose of the body. Like RFC, lots of numbers are used up proposing interfaces that are never used by anyone. In amongst the thousands of RFCs there are perhaps 100 important ones. My sense is we should mirror this approach, allow people to take XLS numbers to propose their idea and if no one has valid criticisms, i.e. it's not widely panned, let the XLS standard be established. If people start to use the standard then a revision to the standard might attract increased attention and/or a new standard might need to emerge to fix deficiencies in the old one. Since this ecosystem suffers from, at least for now, a lack of participation using a time based "acquiescence" approach for allowing standards out of draft makes sense to me. But I'm happy to hear everyone else's thoughts on it. |
Beta Was this translation helpful? Give feedback.
-
|
I see. I 100% agree we shouldn't be guarding numbers like treasure. Even with Python PEPs and C++ proposals, numbers are freely handed out to ideas that never cross the finish line. I agree we shouldn't have a high bar for what is merged into this collection of documents. I guess I was assuming that "standard" has a stronger meaning than "request for comments" or "proposal" or "specification". "Standard" makes me feel that a large group has agreed to it, which should carry a higher bar for reaching the status of "accepted". Even RFCs match this intuition, where an RFC is elevated to Internet Standard only by the judgment of the IETF. Perhaps we could call these RFCs or Proposals or Specifications and attach a Status to each one, much like Python does in their PEP Preamble, or the way IETF distinguishes Internet Draft from Proposed Standard from Internet Standard. In fact, when I recommended we formalize the process, that's much like PEP 1 which lays out the process for Python Enhancement Proposals, or the IETF does with RFCs 2026 and 6410. Each Proposal could start with |
Beta Was this translation helpful? Give feedback.
-
|
Agree standard probably isn’t the correct term but like RFC I expect each XLS will exist on a sliding continuum from a literal request for community comments to a description of current best practices to full blown standards adopted widely. Therefore tongue in cheek I suggest we implicitly backronym XLS to: XRPL Ledger ( Suggestion | Summary | Standard ) as applicable to the individual submission. I still think for maximum ease of submission XLS drafts should start as an issue but I can see the benefit of requiring a PR |
Beta Was this translation helpful? Give feedback.
-
|
I feel we should use the new Github "Discussions" feature from now on.
I propose these Discussion categories: |
Beta Was this translation helpful? Give feedback.
-
If these standards are submitted as pull requests instead of issues, then:
Beta Was this translation helpful? Give feedback.
All reactions