Commit d49881f

@@ -0,0 +1,183 @@
+---
+authors: Bryon <bryon@fryer.io>
+state: discussion
+discussion: https://github.com/knight-work/rfd/pull/1
+labels: process
+---
+
+# Requests for Discussion
+
+Writing down ideas is important: it allows them to be rigorously formulated (even while nascent), candidly discussed and transparently shared. We capture the written expression of an idea in a Request for Discussion (RFD), a document in the original spirit of the [IETF Request for Comments], as expressed by [RFC 3].
+
+> The content of a note may be any thought, suggestion, etc. related to the software or other aspect of the network. Notes are encouraged to be timely rather than polished. Philosophical positions without examples or other specifics, specific suggestions or implementation techniques without introductory or background explication, and explicit questions without any attempted answers are all acceptable. The minimum length for a note is one sentence.
+
+
+> These standards (or lack of them) are stated explicitly for two reasons. First, there is a tendency to view a written statement as ipso facto authoritative, and we hope to promote the exchange and discussion of considerably less than authoritative ideas. Second, there is a natural hesitancy to publish something unpolished, and we hope to ease this inhibition.
+
+
+Similar to RFCs, our philosophy of RFDs is to allow both timely discussion of rough ideas, while still becoming a permanent repository for more established ones. Depending on their state, RFDs may be quickly iterated on in a branch, discussed actively as part of a pull request to be merged, or commented upon after having been published. The workflow for the RFD process for is based upon those of the Golang proposal process, Joyent RFD process, Rust RFC process, Kubernetes proposal process and the [Oxide Request for Discussion Process].
+
+
+## When to use an RFD
+
+The following are examples of when an RFD is appropriate, these are intended to be broad:
+
+ - Add or change a organization process
+ - An architectural or design decision for hardware or software
+ - Change to an API or command-line tool used by customers
+ - Change to an internal API or tool
+ - Change to an internal process
+ - A design for testing
+
+RFDs not only apply to technical ideas but overall organization ideas and processes as well. If you have an idea to improve the way something is being done as a organization, you have the power to make your voice heard by adding to discussion.
+
+## RFD Metadata and State
+
+At the start of every RFD document, we’d like to include a brief amount of metadata. We do this with [YAML frontmatter attributes]. It looks like:
+
+```md
+authors: bryfry, ajpatri
+state: prediscussion
+discussion:
+labels: comma, separated, labels
+```
+
+We keep track of four pieces of metadata:
+
+1. `authors`: The authors (and therefore owners) of an RFD. They should be listed with their name and e-mail address.
+2. `state`: Must be one of the states discussed below.
+3. `discussion`: For RFDs that are in or beyond the `published` state, this should be a link to the PR to integrate the RFD; see below for details.
+4. `labels`: A comma separated list of text labels that specify high-level categories that the RFD falls into, designed to make searching easier. For example, control-plane, hypervisor, process, corp, etc.
+
+An RFD can be in one of the following six states:
+
+- `prediscussion`
+- `ideation`
+- `discussion`
+- `published`
+- `committed`
+- `abandoned`
+
+A document in the `prediscussion` state indicates that the work is not yet ready for discussion, but that the RFD is effectively a placeholder. The `prediscussion` state signifies that work iterations are being done quickly on the RFD in its branch in order to advance the RFD to the `published` state.
+
+A document in the `ideation` state contains only a description of the topic that the RFD will cover, providing an indication of the scope of the eventual RFD. Unlike the `prediscussion` state, there is no expectation that it is undergoing active revision. Such a document can be viewed as a scratchpad for related ideas. Any member of the team is encouraged to start active development of such an RFD (moving it to the `prediscussion` state) with or without the participation of the original author. It is critical that RFDs in the `ideation` state are clear and narrowly defined.
+
+Documents under active discussion should be in the `published` state. At this point a discussion is being had for the RFD in a Pull Request.
+
+Once (or if) discussion has converged and the Pull Request is ready to be merged, it should be updated to the `published` state before merge. Note that just because something is in the `published` state does not mean that it cannot be updated and corrected. See the Making changes to an RFD section for more information.
+
+The `prediscussion` state should be viewed as essentially a collaborative extension of an engineer’s notebook, and the `discussion` state should be used when an idea is being actively discussed. These states shouldn’t be used for ideas that have been committed to, organizationally or otherwise; by the time an idea represents the consensus or direction, it should be in the `published` state.
+
+Once an idea has been entirely implemented, it should be in the `committed` state. Comments on ideas in the `committed` state should generally be raised as issues — but if the comment represents a call for a significant divergence from or extension to committed functionality, a new RFD may be called for; as in all things, use your best judgment.
+
+Finally, if an idea is found to be non-viable (that is, deliberately never implemented) or if an RFD should be otherwise indicated that it should be ignored, it can be moved into the `abandoned` state.
+
+We will go over this in more detail. Let’s walk through the life of a RFD.
+
+## RFD life-cycle
+
+**NOTE:** Never at anytime through the process do you push directly to the `main` branch. Once your pull request (PR) with your RFD in your branch is merged into `main`, then the RFD will appear in the `main` branch.
+
+
+### Reserve a RFD number
+
+You will first need to reserve the number you wish to use for your RFD. This number should be the next available RFD number from looking at the current `git branch -r` output.
+
+#### Create a branch for your RFD
+
+Now you will need to create a new git branch, named after the RFD number you wish to reserve. This number should have leading zeros if less than 4 digits. Before creating the branch, verify that it does not already exist:
+
+```bash
+$ git branch -rl *0042
+```
+
+If you see a branch there (but not a corresponding sub-directory in `rfd` in `main`), it is possible that the RFD is currently being created; stop and check with others before proceeding! Once you have verified that the branch doesn’t exist, create it locally and switch to it:
+
+```bash
+$ git checkout -b 0042
+```
+
+#### Create a placeholder RFD
+
+Now create a placeholder RFD. You can do so with the following commands:
+
+```bash
+$ mkdir -p rfd/0042
+$ cp prototypes/prototype.md rfd/0042/README.md
+```
+
+Fill in the RFD number and title placeholders in the new doc and add your name as an author. The status of the RFD at this point should be prediscussion.
+
+#### Push your RFD branch remotely
+
+Push your changes to your RFD branch in the RFD repo.
+
+```bash
+$ git add rfd/0042/README.md
+$ git commit -m '0042: Adding placeholder for RFD <Title>'
+$ git push origin 0042
+```
+
+After your branch is pushed, the table in the README on the main branch will update automatically with the new RFD. If you ever change the name of the RFD in the future, the table will update as well. Whenever information about the state of the RFD changes, this updates the table as well. The single source of truth for information about the RFD comes from the RFD in the branch until it is merged.
+
+### Iterate on your RFD in your branch
+
+Now, you can work on writing your RFD in your branch.
+
+```bash
+$ git checkout 0042
+```
+
+Now you can gather your thoughts and get your RFD to a state where you would like to get feedback and discuss with others. It’s recommended to push your branch remotely to make sure the changes you make stay in sync with the remote in case your local gets damaged.
+
+It is up to you as to whether you would like to squash all your commits down to one before opening up for feedback, or if you would like to keep the commit history for the sake of history.
+
+### Discuss your RFD
+
+When you are ready to get feedback on your RFD, make sure all your local changes are pushed to the remote branch. At this point you are likely at the stage where you will want to change the status of the RFD from `prediscussion` to `discussion` for a fully formed RFD or to `ideation` for one where only the topic is specified. Do this in your branch.
+
+#### Push your RFD branch remotely
+
+Along with your RFD content, update the RFD’s state to discussion in your branch, then:
+
+```bash
+$ git commit -am '0042: Add RFD for <Title>'
+$ git push origin 0042
+```
+
+#### Open a Pull Request
+
+Open a pull request on GitHub to merge your branch, in this case 0042 into the main branch.
+
+After the pull request is opened, anyone subscribed to the repo will get a notification that you have opened a pull request and can read your RFD and give any feedback.
+
+#### Discuss the RFD on the pull request
+
+The comments you choose to accept from the discussion are up to you as the owner of the RFD, but you should remain empathetic in the way you engage in the discussion.
+
+For those giving feedback on the pull request, be sure that all feedback is constructive. Put yourself in the other person’s shoes and if the comment you are about to make is not something you would want someone commenting on an RFD of yours, then do not make the comment.
+
+#### Merge the Pull Request
+
+After there has been time for folks to leave comments, the RFD can be merged into `main` and changed from the `discussion` state to the `published` state. The timing is left to your discretion: you decide when to open the pull request, and you decide when to merge it. As a guideline, 3-5 business days to comment on your RFD before merging seems reasonable — but circumstances (e.g., time zones, availability of particular expertise, length of RFD) may dictate a different timeline, and you should use your best judgment. In general, RFDs shouldn’t be merged if no one else has read or commented on it; if no one is reading your RFD, it’s time to explicitly ask someone to give it a read!
+
+Discussion can continue on `published` RFDs! The discussion: link in the metadata should be retained, allowing discussion to continue on the original pull request. If an issue merits more attention or a larger discussion of its own, an issue may be opened, with the synopsis directing the discussion.
+
+Any discussion on an RFD can still be made on the original pull request to keep the sprawl to a minimum. Or if you feel your comment post-merge requires a larger discussion, an issue may be opened on it — but be sure to reflect the focus of the discussion in the issue synopsis (e.g., "RFD 42: add consideration of RISC-V"), and be sure to link back to the original PR in the issue description so that one may find one from the other.
+
+### Making changes to an RFD
+
+Even after an RFD has been moved to the `published` state, changes may be made. Whereas development of a new RFD happens in a single branch and associated pull request, a published RFD may have multiple, independent changes being proposed thus necessitating multiple branches and pull requests. Similar in concept to a feature branch, each logically independent change to an RFD is placed into a separate branch named after the RFD number and the focus of the change (e.g. `0001_rfd_modification`). Once a change branch is ready for broader review and feedback, open a pull request requesting to merge the change branch (e.g. `0001_rfd_modification`) into the main branch with the original RFD authors as reviewers. The discussion and merge process as described previously for new RFDs is then followed.
+
+### Committing to an RFD
+
+Once an RFD has become implemented — that is, once it is not an idea of some future state but rather an explanation of how a system works — its state should be moved to be `committed`. This state is essentially no different from published, but represents ideas that have been more fully developed. While discussion on `committed` RFDs is permitted (and changes allowed), they would be expected to be infrequent.
+
+## Tooling
+
+Because RFDs are important to how we communicate information, we've created these tools for decreasing friction with the system. 
+
+[IETF Request for Comments]: https://en.wikipedia.org/wiki/Request_for_Comments
+[RFC 3]: https://datatracker.ietf.org/doc/html/rfc3
+[Oxide Request for Discussion Process]: https://rfd.shared.oxide.computer/rfd/0001
+[YAML frontmatter attributes]: https://pandoc.org/MANUAL.html#extension-yaml_metadata_block

@@ -0,0 +1,82 @@
+---
+authors: Bryon <bryon@fryer.io>
+state: pre-discussion
+labels: business, product, affiliate, email
+---
+
+# RFC 002: buylater.email – An Email Based Delayed Gratification Shopping System
+
+## Summary
+
+`buylater.email` is a minimalist, privacy-first email service that delays gratification by letting users schedule product reminder emails for a future date. Users submit a link and their email address, and we send them a timed reminder with affiliate and add-to-cart links, no passwords, no upsells, no tracking.
+
+The service is monetized purely via affiliate commissions and designed to be transparent, consumer-centric, and willpower-enhancing.
+
+## Motivation
+
+Modern e-commerce is designed to encourage impulse buying. Many people struggle with overconsumption, addictive habits, or simply want to buy less and buy better. Tools that claim to support intentional spending are often tied to tracking, upsells, or hidden agendas. We want to offer a clean, honest alternative.
+
+We believe there is power in *not buying now*. We want to create a simple, no-nonsense, repeatable behavior: “Email this to me next month and if I still want it, I’ll buy it.”
+
+By restoring friction to the buying process, we help people make purchases on their own terms.
+
+## Goals
+
+- Let users submit any product URL and schedule a future email reminder.
+- Embed affiliate links and add-to-cart links in the email.
+- Operate on a minimal infrastructure with minimal user data retention.
+- Reach profitability at a minimal scale (1,000 users/month).
+- Stay focused on simplicity: no passwords, no app, no fluff.
+
+## Non-Goals
+
+- We will not track user behavior outside of what is strictly necessary.
+- We will not up-sell or advertise to our users.
+- We will not sell user data to a third-party.
+
+## Detailed Proposal
+
+### User Flow
+
+1. User visits `buylater.email`.
+2. User pastes a product link and enters their email.
+3. User selects a delay time (e.g., “3 days,” “2 weeks,” or “custom date”).
+4. A confirmation email is sent (to validate ownership and prevent spam).
+5. After confirmation, the service schedules a scheduled email to be sent after the specified delay.
+6. The final email includes:
+   - The original product title and image (fetched at submission).
+   - Affiliate-tagged product link.
+   - Optional “Add to Cart” link for convenience.
+
+### Monetization
+
+- Affiliate program:
+  - Every link in the final email uses a hardcoded affiliate tag.
+  - If a user purchases within the session, a small commission is earned.
+- No upsells, ads, or user data sales.
+
+### UX Philosophy
+
+- Extremely lightweight and fast.
+- No signups or logins.
+- Accessible and mobile-friendly.
+- Encourages mindful spending by intentionally *not* helping users buy faster.
+
+## Alternatives Considered
+
+| Option | Description | Reason Not Chosen |
+|--------|-------------|-------------------|
+| Full wishlist manager | Save/delete items, track price history | Too much overhead and feature creep |
+| Browser extension | Monitor tabs or pages visits | Breaks privacy-first principle, adds complexity |
+| App store product | Native app experience | Increases friction, requires ongoing updates and support |
+| Ads | Monetize with display ads | Conflicts with no-BS user promise |
+
+## Risks & Mitigation
+
+| Risk | Severity | Mitigation |
+|------|----------|------------|
+| Email deliverability issues | High | Use warm sender domain and reputable provider (Postmark, SES w/ dedicated IP) |
+| Abuse (spam input) | Medium | Use double opt-in and rate limiting |
+| Affiliate link breakage | Low | Use direct product URLs with embedded affiliate tags |
+| Low commission revenue | Medium | Optimize CTA placement, consider other affiliate programs only if ethical alignment maintained |
+| Amazon policy changes | Medium | Maintain compliance with Amazon Associates terms; minimize reliance on scraping or deprecated APIs |

@@ -0,0 +1,1 @@
+docs/lets-go/*