Merge branch 'master' into tutorial-page

content/_code-samples/build-a-wallet/js/.env

@@ -1,3 +1,3 @@
-CLIENT="wss://s.altnet.rippletest.net/"
+CLIENT="wss://s.altnet.rippletest.net:51233/"
 EXPLORER_NETWORK="testnet"
 SEED="s████████████████████████████"

content/concepts/consensus-network/amendments/contribute-code-flow.md

@@ -0,0 +1,82 @@
+---
+html: contribute-code-flow.html
+parent: amendments.html
+blurb: 
+labels:
+  - Blockchain
+---
+# Contribute Code to the XRP Ledger
+
+The software that powers the XRP Ledger is open source. Anyone can download, modify, extend, or explore it. If you want to contribute code, it's important to work with the community to define the specifications of your changes and test the code before adding it to `rippled`.
+
+
+## XRP Ledger Standards
+
+Changes to `rippled` are tracked by an XRP Ledger Standard (XLS), a document that identifies and details the specifications of a change. Before committing to development, you must start a discussion in the [XRPL-Standards repo](https://github.com/XRPLF/XRPL-Standards/discussions). This provides the community a chance to discuss and provide feedback about your change.
+
+**Note:** Bug fixes don't require an XLS, but may require an amendment.
+
+Creating an XLS has its own process, but can be summarized as:
+
+1. Start a discussion and gather feedback.
+2. Create an XLS draft in the standards repo.
+3. Publishing the XLS draft as a Candidate Specification.
+
+For details, see the [XLS contributing guide](https://github.com/XRPLF/XRPL-Standards/blob/master/CONTRIBUTING.md).
+
+
+## Amendment Implementation
+
+After you've created an XLSd, you now need to determine if your change requires an amendment. Changes that affect **transaction processing** require amendments, specifically changes that:
+
+- Modify ledger rules, resulting in different outcomes.
+- Add or remove transactions.
+- Affect consensus.
+
+**Note:** If your change doesn't need an amendment, you can go straight to coding and deployment.
+
+Implementing code as an amendment requires you to add the amendment to these files:
+
+- **Feature.cpp**:
+
+  `Supported` parameter should be set to `no` until development is complete.
+
+  `DefaultVote` parameter should be set to `yes` for bug fixes; everything else defaults to `no`.
+
+- **Feature.h**: Increment the `numFeatures` counter and declare an `extern uint256 const` variable.
+
+
+## Coding and Deployment
+
+The general development path breaks down as follows:
+
+1. Create a fork or branch in the [`rippled` repository](https://github.com/XRPLF/rippled) to develop your code.
+
+    **Tip:** If you're not sure where to start, _Dev Null Productions_ provides a detailed and thorough [`rippled` Source Code Guide](https://xrpintel.com/source).
+
+2. Run unit and integration tests. Running a server in _stand-alone mode_ is useful for testing your changes in an isolated environment, but you may want to stand up a private network for extensive changes.
+
+3. Create a pull request on `XRPLF:develop`.
+
+    **Note for Amendments:** Update the `Supported` paramter to `yes` in **Feature.cpp**.
+
+4. After the pull request is approved by XRP Ledger maintainers, your code is merged into `develop` and additional testing can be done on Devnet.
+
+    **Note for Amendments:**
+    - The `DefaultVote` parameter is now locked.
+    - If problems are found with the amendment, you must restart the process of making fixes and submitting a new PR. You can change the default vote in the new PR.
+
+5. On a quarterly basis, a release candidate is built from approved PRs on `develop`. The package is deployed to Testnet and a few nodes on Mainnet. If no issues are found with the release candidate, the code is merged into `master` and nodes on Mainnet can upgrade to this build.
+
+6. New amendments go through the consensus process and validators vote on whether to enable them.
+
+
+## Code Flowchart
+
+![Code Flowchart](img/Contribute Code Flowchart.png)
+
+
+## See Also
+
+- **Concepts:**
+    - [Amendments](amendments.html)

content/concepts/tokens/nftoken-auctions.md

@@ -47,7 +47,7 @@ This is the most complex workflow of the three.
 
 1. The seller creates an NFT using `NFTokenMint`.
 1. The bidders make offers using `NFTokenCreateOffer`, setting the broker as the destination.
-1. The broker selects the winning bid, subtracts the amount to be collected as a fee, then requests the seller sign a sell off for this amount via `NFTokenCreateOffer`.
+1. The broker selects the winning bid, subtracts the amount to be collected as a fee, then requests the seller sign a sell offer for this amount via `NFTokenCreateOffer`.
 1. The seller signs the requested offer, setting the broker as the destination.
 1. The broker completes the sale using `NFTokenAcceptOffer`, and receives the broker fee.
 1. The broker cancels any remaining bids using `NFTokenCancelOffer`.

content/contributing/tutorial-guidelines.md

@@ -0,0 +1,85 @@
+---
+html: tutorial-guidelines.html
+parent: contribute.html
+---
+
+# Tutorial Guidelines
+
+We are creating a modular tutorial framework that allows developers to learn how transactions and requests work on the XRP Ledger. Developers can review the modules to learn about business solutions, and potentially repurpose the scripts in their own applications.
+
+
+# Rationale
+
+What a developer wants comes down to two things:
+
+1. Sample code snippets they can copy and paste into their own applications.
+2. Complete API reference documentation.
+
+Keep the conceptual information to a minimum – only the information necessary to complete the tutorial. For background or deeper understanding, provide links to the conceptual topics at the end of the tutorial, if needed.
+
+Modular tutorials follow Malcolm Knowles’ six assumptions for designing adult learning:
+
+1. Adults need to know why they need to learn something.
+2. Adults need to build on their experience.
+3. Adults have a need to feel responsible for their learning.
+4. Adults are ready to learn if training solves an immediate problem.
+5. Adults want their training to be problem focused.
+6. Adults learn best when motivation comes intrinsically.
+
+Add into that Ralph Smedley’s quote, “We learn best in moments of enjoyment.” Taking a lighter touch helps to relax the learner so that the material flows into their brain with less resistance.
+
+
+# Sample Code vs. Tasks vs. Concepts vs. Tutorials
+
+To date, there have been some blurred lines where different types of documentation show up as _Tutorials._ Here are some comparisons that help define the distinction.
+
+
+## Sample Code
+
+Sample code is well commented snippets or applications that illustrate best practices for implementing a feature of the API. Sample code is modular and reusable with little customization required. 
+
+Sample code is desirable, because advanced users can typically scan the example and use it immediately without a formal tutorial. It can also be used by others as a basis for tutorials. Sample code developers can focus on what they do well, while technical writers and support personnel can use the samples to create quality training materials.
+
+
+## Tasks
+
+Tasks are step-by-step instructions for how to accomplish a specific result. For example, “Installing rippled on a Red Hat Linux Server.” Task documentation is not intended to be particularly educational. It frequently describes tasks that are only performed one time per implementation, or maintenance tasks that always follow a familiar pattern. Tasks provide troubleshooting guidance, since there are likely variables that the user must adjust based on the specifics of their use case.
+
+
+## Concepts
+
+Conceptual information describes elements of the API, how they work, and when to use them. If a tutorial requires lengthy explanations before or during the programming tasks, consider how you might separate the exposition into a new topic, or link to existing topics that set the proper context. 
+
+For example, three paragraphs of context and a single line of code would be a concept, not a tutorial.
+
+
+## Tutorials
+
+Tutorials begin with sample code that illustrates best practices for implementing a feature. They take the developer step-by-step through the development process, explaining the purpose of each block of code.
+
+Tutorials further combine a number of features to work together to solve a business problem. They describe the straightforward sunny day path to complete a task. Then, the tutorial might suggest modifications that let the developer try several different scenarios. Due to their focus on a certain limited scope of behavior, tutorials should not require extensive troubleshooting information.
+
+
+## Use Cases
+
+Use cases describe how to pull together multiple features to create a practical application that solves a business problem. They provide context and assistance with the decision making process, then provide links to the appropriate topics for each step of implementation. 
+
+
+# Tutorial Components
+
+This section describes the elements of the modular tutorials used on XRPL.org.
+
+
+## Sample Application
+
+XRPL tutorial code samples are modular in nature. For example, Script 1 demonstrates how to create a test account, access the XRP Ledger, and transfer XRP between accounts. Any further samples can reuse the functions in Script 1.
+
+Create a new script with the specific, minimal function code required to demonstrate the practical solution to a business problem. The examples should be incremental, with just enough behaviors to illustrate a business process.
+
+For example, the first NFT tutorial shows how to mint, retrieve, and burn an NFT. The next tutorial shows how to create and accept a sell offer, and create and accept a buy offer.
+
+Don’t focus too much on the UX of the application, unless the look and feel is pertinent to the topic. Use the standard CSS file with the look and feel for all of the tutorials.
+
+Reuse the code from other modules when possible. There might be situations where you need to modify the behavior from an earlier module. You can either overload the function name or modify the module and save it with a different name.
+
+

content/contributing/tutorial-structure.md

@@ -0,0 +1,54 @@
+---
+html: tutorial-structure.html
+parent: contribute.html
+---
+
+# Tutorial Structure
+
+Each XRP Ledger tutorial follows the same format.
+
+1. A brief description of the features illustrated in the tutorial.
+2. Prerequisites for running the code, if needed, or links to the sample code.
+3. Usage examples of the features in the tutorial.
+4. A code walkthrough of the sample application, highlighting unique elements in the scripts.
+5. See Also, with links to conceptual information or good tutorials to try as a next step.
+
+Separate setup (prerequisites) from usage from code development. These are each different activities that engage different areas of the brain. Trying to think of all three elements at once leads to confusion and headaches.
+
+## Description
+
+![Description](img/tut-struct1.png)
+
+List what the sample demonstrates. If possible, each example should describe the steps to accomplish specific related tasks. (For example, create a NFT Sell Offer, Accept a Sell Offer, Delete a Sell Offer.)  There should be enough conceptual information to understand what the tutorial illustrates, with links to additional conceptual information, if needed.
+
+## Prerequisites
+
+![Prerequisites](img/tut-struct2.png)
+
+Provide links to any required software and to all of the example code needed to run the tutorial. If necessary, give simple instructions for using third-party tools, but provide a link to the source website for the customer to do a deeper dive at their leisure.
+
+## Usage Example
+
+![Usage](img/tut-struct3.png)
+
+Start by providing a finished, working example of the tutorial application. This is an opportunity for immediate success working with the software to solve a problem.
+
+Use screenshots for each step of the tutorial – these allow the user to understand the tutorial without having to run the code themselves. Of course we _want_ them to run the code, but this gives them a choice.
+
+Describe the sunny day scenario. The application should run without problems if there is an uninterrupted connection to the internet. Don’t provide a lot of troubleshooting information, unless it’s pertinent to the tutorial.
+
+## Code Walkthrough
+
+![Code Walkthrough](img/tut-struct4.png)
+
+Walk through the code, one chunk at a time. Don’t belabor topics that have been discussed in earlier examples. Provide sample code, but don’t provide exhaustive explanations for how to program underlying platforms like HTML syntax unless there is something unique to the implementation.
+
+An important thing to emphasize is that every interaction with the XRPL is either a transaction or a request, and that all transactions and requests are essentially the same. The sample code we provide shows how to prepare the transaction or request, and how to process the returned results. Knowing how to submit and respond to one transaction or request gives a pretty good idea for how to submit and respond to any transaction or request.
+
+(Technically there is third category, similar to a request: a notification from a subscription stream. See [Subscription Methods](subscription-methods.html).)
+
+## See Also
+
+![See Also](img/tut-struct5.png)
+
+At the end of the tutorial, provide links to additional resources, conceptual information, and any tutorials that would be a sensible next step in the learning journey.

content/references/protocol-reference/data-types/nftoken.md

@@ -20,7 +20,6 @@ Example {{currentpage.name}} JSON
 }
 ```
 
-
 Unlike full-fledged [ledger entries](ledger-object-types.html), `NFToken` has no field to identify the object type or current owner of the object. `NFToken` objects are grouped into pages that implicitly define the object type and identify the owner.
 
 
@@ -37,13 +36,10 @@ This composite field uniquely identifies a token, and consists of the following
 4. A 32-bit issuer-specified [`NFTokenTaxon`](https://www.merriam-webster.com/dictionary/taxon)
 5. An (automatically generated) monotonically increasing 32-bit sequence number.
 
-
 ![Token ID Breakdown](img/nftoken1.png "Token ID Breakdown")
 
-
 The 16-bit flags, transfer fee fields, the 32-bit `NFTokenTaxon`, and the sequence number fields are stored in big-endian format.
 
-
 ## NFToken Flags
 
 Flags are properties or other options associated with the `NFToken` object.
@@ -59,36 +55,29 @@ Flags are properties or other options associated with the `NFToken` object.
 
 `NFToken` flags are immutable: they can only be set during the [NFTokenMint transaction][] and cannot be changed later.
 
-
 ### Example
 
 The example sets three flags: `lsfBurnable` (`0x0001`), `lsfOnlyXRP` (`0x0002`), `lsfTransferable` (`0x0008`). 1+2+8 = 11, or `0x000B` in big endian format.
 
 ![Flags](img/nftokena.png "Flags")
 
-
 ### TransferFee
 <!-- SPELLING_IGNORE: transferfee -->
 
 The `TransferFee` value specifies the percentage fee, in units of 1/100,000, charged by the issuer for secondary sales of the token. Valid values for this field are between 0 and 50,000, inclusive. A value of 1 is equivalent to 0.001% or 1/10 of a basis point (bps), allowing transfer rates between 0% and 50%.
 
-
 ### Example
 
 This value sets the transfer fee to 314, or 0.314%.
 
 ![Transfer Fee](img/nftokenb.png "Transfer Fee")
 
-
-
 ### Issuer Identification
 
 The third section of the `NFTokenID` is a big endian representation of the issuer’s public address.
 
 ![Issuer Address](img/nftokenc.png "Issuer Address")
 
-
-
 ### NFTokenTaxon
 <!-- SPELLING_IGNORE: nftokentaxon -->
 
@@ -114,38 +103,28 @@ The URI field points to the data or metadata associated with the `NFToken`. This
 
 **Caution:** The URI is immutable, so no one can update it if, for example, it links to a website that no longer exists.
 
-
 # Retrieving NFToken Data and Metadata
 
 To minimize the footprint of `NFTokens` without sacrificing functionality or imposing unnecessary restrictions, XRPL NFTs do not have arbitrary data fields. Instead, data is maintained separately and referenced by the `NFToken`. The URI provides a reference to immutable content for the `Hash` and any mutable data for the `NFToken` object.
 
 The `URI` field is especially useful for referring to non-traditional Peer-to-Peer (P2P) URLs. For example, a minter that stores `NFToken` data or metadata using the Inter Planetary File System (IPFS) can use the `URI` field to refer to data on IPFS in different ways, each of which is suited to different use-cases. For more context on types of IPFS links that can be used to store NFT data, see [Best Practices for Storing NFT Data using IPFS](https://docs.ipfs.io/how-to/best-practices-for-nft-data/#types-of-ipfs-links-and-when-to-use-them),
 
-An alternative to the URI approach is for issuers of `NFToken` objects to set the `Domain` field of their issuing account to the correct domain, and offer an API for clients that want to lookup the data or metadata associated with a particular `NFToken`. Note that using this mechanism _requires_ the minter to acquire a domain name and set the domain name for their minting account, but does not require the minter to necessarily run a server nor other service to provide the ability to query this data; instead, a minter can "redirect" queries to a data provider (for example, to a marketplace, registry or other service).
-
-Your implementation should first attempt to check for the presence of the `URI` field to retrieve the associated data or metadata. If the `URI` field does not exist, the implementation should check for the presence of `Domain` field. If neither field exists, nothing happens. Implementations must be prepared to handle HTTP redirections (for example, using HTTP responses 301, 302, 307 and 308) from the URI.
-
-
 ## TXT Record Format
 
 The format for a text record is as follows.
 
-
 ```
 xrpl-nft-data-token-info-v1 IN TXT "https://host.example.com/api/token-info/{nftokenid}"
 ```
 
-
 Replace the string `{nftokenid}` with the requested `NFTokenID` as a 64-byte hex string when you attempt to query information.
 
 Your implementation should check for the presence of `TXT` records and use those query strings if present. If no string is present, implementations should attempt to use a default URL. Assuming the domain is _example.com_, the default URL would be:
 
-
 ```
 https://example.com/.well-known/xrpl-nft/{nftokenid}
 ```
 
-
 You create `NFToken` objects using the `NFTokenMint` transaction. You can optionally destroy `NFToken` objects using the `NFTokenBurn` transaction.
 
 <!--{# common link defs #}-->

dactyl-config.yml

@@ -1053,6 +1053,11 @@ pages:
         targets:
             - ja
 
+    -   md: concepts/consensus-network/amendments/contribute-code-flow.md
+        targets:
+            - en
+            - ja
+
     -   md: concepts/consensus-network/amendments/known-amendments.md
         targets:
             - en
@@ -4488,7 +4493,7 @@ pages:
         html: contribute-code-to-rippled.html
         template: pagetype-redirect.html.jinja
         nav_omit: true
-        redirect_url: contribute-code.html
+        redirect_url: contribute-code-flow.html
         targets:
             - en
 
@@ -4496,7 +4501,7 @@ pages:
         html: contribute-code-to-rippled.html
         template: pagetype-redirect.html.jinja
         nav_omit: true
-        redirect_url: contribute-code.html
+        redirect_url: contribute-code-flow.html
         targets:
             - ja
 
@@ -4504,7 +4509,7 @@ pages:
         html: contribute-code-to-ripple-lib.html
         template: pagetype-redirect.html.jinja
         nav_omit: true
-        redirect_url: contribute-code.html
+        redirect_url: contribute-code-flow.html
         targets:
             - en
 
@@ -4512,7 +4517,7 @@ pages:
         html: contribute-code-to-ripple-lib.html
         template: pagetype-redirect.html.jinja
         nav_omit: true
-        redirect_url: contribute-code.html
+        redirect_url: contribute-code-flow.html
         targets:
             - ja
 
@@ -4732,6 +4737,24 @@ pages:
             - en
             - ja
 
+    # TODO: translate
+    -   md: contributing/tutorial-guidelines.md
+        html: tutorial-guidelines.html
+        parent: contribute-code.html
+        top_nav_omit: true
+        targets:
+            - en
+            - ja
+
+    # TODO: translate
+    -   md: contributing/tutorial-structure.md
+        html: tutorial-structure.html
+        parent: tutorial-guidelines.html
+        top_nav_omit: true
+        targets:
+            - en
+            - ja
+
     -   name: Events
         html: events.html
         parent: contribute.html

styles/_docs-landing.scss

@@ -172,6 +172,16 @@
   h1 {
     font-size: 3.875rem;
   }
+
+  .arrow-purple::after {
+    content: url(../img/icons/arrow-right-purple.svg);
+  }
+
+  .documentation-index:hover, .documentation-index::after {
+    color: $purple;
+    text-decoration: none !important;
+    background: none !important;
+  }
 } 
 
 @media (max-width: 765px) {

styles/_pages.scss

@@ -919,6 +919,7 @@
     position: relative;
     z-index: 5;
     width: 100%;
+    transform: translateY(0%);
 
     p a {
       text-decoration: none;

styles/package.json

@@ -4,9 +4,9 @@
     "node-sass": "^7.0.0"
   },
   "scripts": {
-    "build-css": "node-sass --include-path scss xrpl.scss ../assets/css/devportal2022-v17.css --output-style compressed",
-    "build-css-out": "node-sass --include-path scss xrpl.scss ../out/assets/css/devportal2022-v17.css --output-style compressed --source-map true",
-    "build-css-watch-out": "node-sass --recursive --watch  --include-path scss xrpl.scss ../out/assets/css/devportal2022-v17.css --output-style compressed --source-map true"
+    "build-css": "node-sass --include-path scss xrpl.scss ../assets/css/devportal2022-v18.css --output-style compressed",
+    "build-css-out": "node-sass --include-path scss xrpl.scss ../out/assets/css/devportal2022-v18.css --output-style compressed --source-map true",
+    "build-css-watch-out": "node-sass --recursive --watch  --include-path scss xrpl.scss ../out/assets/css/devportal2022-v18.css --output-style compressed --source-map true"
   },
   "dependencies": {
     "sass": "^1.26.10"

template/base.html.jinja

@@ -52,7 +52,7 @@
     {% if target.lang=="ja" %}
     <link href="{{currentpage.prefix}}assets/css/fonts-ja.css" rel="stylesheet" />
     {% endif %}
-    <link href="{{currentpage.prefix}}assets/css/devportal2022-v17.css" rel="stylesheet" />
+    <link href="{{currentpage.prefix}}assets/css/devportal2022-v18.css" rel="stylesheet" />
 
     <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/@docsearch/css@3" />
 

template/page-docs.html.jinja

@@ -413,7 +413,7 @@
     </div>
   </section><!-- Browse by recommended and Generate Testnet Credentials -->
   <section class="container-new">
-    <a href="./docs-index.html" class="ml-auto">{% trans %}See full documenation index{% endtrans %}</a>
+    <a href="./docs-index.html" class="btn-arrow arrow-purple documentation-index mr-auto">{% trans %}See full documentation index{% endtrans %}</a>
   </section>
 {% endblock %}