🌱🗜️✨ TOBIAS: TOpical Basic Income Administration System
#1
Labels
✨ enhancement
New feature or request
Comments
zspencer
changed the title
TOBIAS: The TOpical Basic Income Administration SystemTOBIAS: TOpical Basic Income Administration System
zspencer
added a commit
to zinc-collective/convene
that referenced
this issue
Jan 8, 2024
- #709 - zinc-collective#1 This is an attempt at using a README as a form of product-design documentation. It follows the Pain-Dream-Fix recipe for marketing copy, with an emphasis on the code's *purpose*. By exposing the purpose of the code; new contributors (or contributors that have been away for a bit) have a way of grounding themselves in the product-thinking behind the project itself. That said, good README's have additional context beyond the purpose, such as: - A Data Model, which exposes a high-level view of the interactions between entities within the system we are building. - Setup instructions, such as guidance for how to populate an initial database or a reference to additional software to install. But for now we don't have either of those things; and I wanted to do some Product-based House Keeping, such as creating Fauxsonas and Use Cases before diving into Engineering.
zspencer
added a commit
that referenced
this issue
Jan 15, 2024
- zinc-collective#709 - #1 This is an attempt at using a README as a form of product-design documentation. It follows the Pain-Dream-Fix recipe for marketing copy, with an emphasis on the code's *purpose*. By exposing the purpose of the code; new contributors (or contributors that have been away for a bit) have a way of grounding themselves in the product-thinking behind the project itself. That said, good README's have additional context beyond the purpose, such as: - A Data Model, which exposes a high-level view of the interactions between entities within the system we are building. - Setup instructions, such as guidance for how to populate an initial database or a reference to additional software to install. But for now we don't have either of those things; and I wanted to do some Product-based House Keeping, such as creating Fauxsonas and Use Cases before diving into Engineering.
zspencer
added a commit
that referenced
this issue
Jan 15, 2024
* 📝 `TOBIAS`: Sprout README as Contributor-Facing Product Marketing - zinc-collective#709 - #1 This is an attempt at using a README as a form of product-design documentation. It follows the Pain-Dream-Fix recipe for marketing copy, with an emphasis on the code's *purpose*. By exposing the purpose of the code; new contributors (or contributors that have been away for a bit) have a way of grounding themselves in the product-thinking behind the project itself. That said, good README's have additional context beyond the purpose, such as: - A Data Model, which exposes a high-level view of the interactions between entities within the system we are building. - Setup instructions, such as guidance for how to populate an initial database or a reference to additional software to install. But for now we don't have either of those things; and I wanted to do some Product-based House Keeping, such as creating Fauxsonas and Use Cases before diving into Engineering.
zspencer
added a commit
to zinc-collective/convene
that referenced
this issue
Jan 23, 2024
- zinc-collective#11 I'm starting out by coding by wishful thinking, putting together the pieces of the pie that I can eat bite by bite. In this test, I'm using imagining there will be a Model called `Tobias::Payout`, which will be our computational entrance point into the [Issuing a Payout](zinc-collective#11) feature. I considered starting with a system test, which would have gone through the User Interface and tied together a bunch of different concepts; but I figured I would start with a `model` spec; so that I can stay focused on drawing the computer-facing side of the feature out before worrying too much about the human-facing bits; which I always find require a lot more thought for me. That said, a system test will be useful here at some point. The computational bits, on the other hand, feel pretty accesible. We want to create Payments for every Beneficiary of the appropriate amount, and store records of these Payments so we know who is supposed to get paid what. Here's a line-by-line play-by-play of this change: I'm using the `spec` folder to store executable examples of a feature. Because `Issuing Payout` is a feature for the [`TOBIAS` project](zinc-collective#1), I am storing it under `spec/tobias`. My choice of what to call the file (`payout_spec.rb` indicates that this spec will be for the `Payout` model. The `require "rails_helper"` line tells our testing framework to load all the code necessary to run a spec. The `describe Tobias::Payout do` line groups the examples nested within it as relating to the `Payout` model. The `describe "#issue"` line tells me that the `Payout` model will have a method named `issue`, and also creates a group of examples that describe how the `Payout#issue` method works. The `it "issues a Payment..." do` line describes one of the examples we we plan to use to confirm that the `Payout#issue` method works the way we hope it will. The test itself lives on the lines between `it "issues a Payment..." do` and the `end` that is aligned with the `it` The `payout = create(:tobias_payout, payout_amount_cents: 150_00) line says "create a database record of a `Tobias::Payout, and populate it's `payout_amount_cents` field with $150.00, and store a reference to it in the `payout` variable. The `beneficiaries = create_list(10, :tobias_beneficiary, trust: payout.trust)` line says create 10 `Tobias::Beneficiary` records in the database, and make sure their `trust` field is pointed at the same `Tobias::Trust` that our `payout` is pointing to. Store references to those in the `beneficiaries variable.` The `payout.issue` line executes the `Payout#issue` method that we are describing. The `beneficiaries.each do |beneficiary|` goes over every one of the newly created `Tobias::Beneficiary` records stored in the `beneficiaries` variable, expose each one as a variable named `beneficiary`, and execute the code between it and the next `end`. The `expect(beneficiaries.payments).to exist(amount_cents)` tells our example to let us know if there are no `Tobias::Payment` records in the database for one of the `beneficiaries`.
zspencer
added a commit
that referenced
this issue
Jan 29, 2024
- #11 I'm starting out by coding by wishful thinking, putting together the pieces of the pie that I can eat bite by bite. In this test, I'm using imagining there will be a Model called `Tobias::Payout`, which will be our computational entrance point into the [Issuing a Payout](#11) feature. I considered starting with a system test, which would have gone through the User Interface and tied together a bunch of different concepts; but I figured I would start with a `model` spec; so that I can stay focused on drawing the computer-facing side of the feature out before worrying too much about the human-facing bits; which I always find require a lot more thought for me. That said, a system test will be useful here at some point. The computational bits, on the other hand, feel pretty accesible. We want to create Payments for every Beneficiary of the appropriate amount, and store records of these Payments so we know who is supposed to get paid what. Here's a line-by-line play-by-play of this change: I'm using the `spec` folder to store executable examples of a feature. Because `Issuing Payout` is a feature for the [`TOBIAS` project](#1), I am storing it under `spec/tobias`. My choice of what to call the file (`payout_spec.rb` indicates that this spec will be for the `Payout` model. The `require "rails_helper"` line tells our testing framework to load all the code necessary to run a spec. The `describe Tobias::Payout do` line groups the examples nested within it as relating to the `Payout` model. The `describe "#issue"` line tells me that the `Payout` model will have a method named `issue`, and also creates a group of examples that describe how the `Payout#issue` method works. The `it "issues a Payment..." do` line describes one of the examples we we plan to use to confirm that the `Payout#issue` method works the way we hope it will. The test itself lives on the lines between `it "issues a Payment..." do` and the `end` that is aligned with the `it` The `payout = create(:tobias_payout, payout_amount_cents: 150_00) line says "create a database record of a `Tobias::Payout, and populate it's `payout_amount_cents` field with $150.00, and store a reference to it in the `payout` variable. The `beneficiaries = create_list(10, :tobias_beneficiary, trust: payout.trust)` line says create 10 `Tobias::Beneficiary` records in the database, and make sure their `trust` field is pointed at the same `Tobias::Trust` that our `payout` is pointing to. Store references to those in the `beneficiaries variable.` The `payout.issue` line executes the `Payout#issue` method that we are describing. The `beneficiaries.each do |beneficiary|` goes over every one of the newly created `Tobias::Beneficiary` records stored in the `beneficiaries` variable, expose each one as a variable named `beneficiary`, and execute the code between it and the next `end`. The `expect(beneficiaries.payments).to exist(amount_cents)` tells our example to let us know if there are no `Tobias::Payment` records in the database for one of the `beneficiaries`.
zspencer
added a commit
that referenced
this issue
Jan 29, 2024
- #11 I'm starting out by coding by wishful thinking, putting together the pieces of the pie that I can eat bite by bite. In this test, I'm using imagining there will be a Model called `Tobias::Payout`, which will be our computational entrance point into the [Issuing a Payout](#11) feature. I considered starting with a system test, which would have gone through the User Interface and tied together a bunch of different concepts; but I figured I would start with a `model` spec; so that I can stay focused on drawing the computer-facing side of the feature out before worrying too much about the human-facing bits; which I always find require a lot more thought for me. That said, a system test will be useful here at some point. The computational bits, on the other hand, feel pretty accesible. We want to create Payments for every Beneficiary of the appropriate amount, and store records of these Payments so we know who is supposed to get paid what. Here's a line-by-line play-by-play of this change: I'm using the `spec` folder to store executable examples of a feature. Because `Issuing Payout` is a feature for the [`TOBIAS` project](#1), I am storing it under `spec/tobias`. My choice of what to call the file (`payout_spec.rb` indicates that this spec will be for the `Payout` model. The `require "rails_helper"` line tells our testing framework to load all the code necessary to run a spec. The `describe Tobias::Payout do` line groups the examples nested within it as relating to the `Payout` model. The `describe "#issue"` line tells me that the `Payout` model will have a method named `issue`, and also creates a group of examples that describe how the `Payout#issue` method works. The `it "issues a Payment..." do` line describes one of the examples we we plan to use to confirm that the `Payout#issue` method works the way we hope it will. The test itself lives on the lines between `it "issues a Payment..." do` and the `end` that is aligned with the `it` The `payout = create(:tobias_payout, payout_amount_cents: 150_00) line says "create a database record of a `Tobias::Payout, and populate it's `payout_amount_cents` field with $150.00, and store a reference to it in the `payout` variable. The `beneficiaries = create_list(10, :tobias_beneficiary, trust: payout.trust)` line says create 10 `Tobias::Beneficiary` records in the database, and make sure their `trust` field is pointed at the same `Tobias::Trust` that our `payout` is pointing to. Store references to those in the `beneficiaries variable.` The `payout.issue` line executes the `Payout#issue` method that we are describing. The `beneficiaries.each do |beneficiary|` goes over every one of the newly created `Tobias::Beneficiary` records stored in the `beneficiaries` variable, expose each one as a variable named `beneficiary`, and execute the code between it and the next `end`. The `expect(beneficiaries.payments).to exist(amount_cents)` tells our example to let us know if there are no `Tobias::Payment` records in the database for one of the `beneficiaries`.
zspencer
added a commit
that referenced
this issue
Jan 30, 2024
- #11 I'm starting out by coding by wishful thinking, putting together the pieces of the pie that I can eat bite by bite. In this test, I'm using imagining there will be a Model called `Tobias::Payout`, which will be our computational entrance point into the [Issuing a Payout](#11) feature. I considered starting with a system test, which would have gone through the User Interface and tied together a bunch of different concepts; but I figured I would start with a `model` spec; so that I can stay focused on drawing the computer-facing side of the feature out before worrying too much about the human-facing bits; which I always find require a lot more thought for me. That said, a system test will be useful here at some point. The computational bits, on the other hand, feel pretty accesible. We want to create Payments for every Beneficiary of the appropriate amount, and store records of these Payments so we know who is supposed to get paid what. Here's a line-by-line play-by-play of this change: I'm using the `spec` folder to store executable examples of a feature. Because `Issuing Payout` is a feature for the [`TOBIAS` project](#1), I am storing it under `spec/tobias`. My choice of what to call the file (`payout_spec.rb` indicates that this spec will be for the `Payout` model. The `require "rails_helper"` line tells our testing framework to load all the code necessary to run a spec. The `describe Tobias::Payout do` line groups the examples nested within it as relating to the `Payout` model. The `describe "#issue"` line tells me that the `Payout` model will have a method named `issue`, and also creates a group of examples that describe how the `Payout#issue` method works. The `it "issues a Payment..." do` line describes one of the examples we we plan to use to confirm that the `Payout#issue` method works the way we hope it will. The test itself lives on the lines between `it "issues a Payment..." do` and the `end` that is aligned with the `it` The `payout = create(:tobias_payout, payout_amount_cents: 150_00) line says "create a database record of a `Tobias::Payout, and populate it's `payout_amount_cents` field with $150.00, and store a reference to it in the `payout` variable. The `beneficiaries = create_list(10, :tobias_beneficiary, trust: payout.trust)` line says create 10 `Tobias::Beneficiary` records in the database, and make sure their `trust` field is pointed at the same `Tobias::Trust` that our `payout` is pointing to. Store references to those in the `beneficiaries variable.` The `payout.issue` line executes the `Payout#issue` method that we are describing. The `beneficiaries.each do |beneficiary|` goes over every one of the newly created `Tobias::Beneficiary` records stored in the `beneficiaries` variable, expose each one as a variable named `beneficiary`, and execute the code between it and the next `end`. The `expect(beneficiaries.payments).to exist(amount_cents)` tells our example to let us know if there are no `Tobias::Payment` records in the database for one of the `beneficiaries`.
zspencer
added a commit
that referenced
this issue
Feb 12, 2024
- #11 I'm starting out by coding by wishful thinking, putting together the pieces of the pie that I can eat bite by bite. In this test, I'm using imagining there will be a Model called `Tobias::Payout`, which will be our computational entrance point into the [Issuing a Payout](#11) feature. I considered starting with a system test, which would have gone through the User Interface and tied together a bunch of different concepts; but I figured I would start with a `model` spec; so that I can stay focused on drawing the computer-facing side of the feature out before worrying too much about the human-facing bits; which I always find require a lot more thought for me. That said, a system test will be useful here at some point. The computational bits, on the other hand, feel pretty accesible. We want to create Payments for every Beneficiary of the appropriate amount, and store records of these Payments so we know who is supposed to get paid what. Here's a line-by-line play-by-play of this change: I'm using the `spec` folder to store executable examples of a feature. Because `Issuing Payout` is a feature for the [`TOBIAS` project](#1), I am storing it under `spec/tobias`. My choice of what to call the file (`payout_spec.rb` indicates that this spec will be for the `Payout` model. The `require "rails_helper"` line tells our testing framework to load all the code necessary to run a spec. The `describe Tobias::Payout do` line groups the examples nested within it as relating to the `Payout` model. The `describe "#issue"` line tells me that the `Payout` model will have a method named `issue`, and also creates a group of examples that describe how the `Payout#issue` method works. The `it "issues a Payment..." do` line describes one of the examples we we plan to use to confirm that the `Payout#issue` method works the way we hope it will. The test itself lives on the lines between `it "issues a Payment..." do` and the `end` that is aligned with the `it` The `payout = create(:tobias_payout, payout_amount_cents: 150_00) line says "create a database record of a `Tobias::Payout, and populate it's `payout_amount_cents` field with $150.00, and store a reference to it in the `payout` variable. The `beneficiaries = create_list(10, :tobias_beneficiary, trust: payout.trust)` line says create 10 `Tobias::Beneficiary` records in the database, and make sure their `trust` field is pointed at the same `Tobias::Trust` that our `payout` is pointing to. Store references to those in the `beneficiaries variable.` The `payout.issue` line executes the `Payout#issue` method that we are describing. The `beneficiaries.each do |beneficiary|` goes over every one of the newly created `Tobias::Beneficiary` records stored in the `beneficiaries` variable, expose each one as a variable named `beneficiary`, and execute the code between it and the next `end`. The `expect(beneficiaries.payments).to exist(amount_cents)` tells our example to let us know if there are no `Tobias::Payment` records in the database for one of the `beneficiaries`.
zspencer
added a commit
that referenced
this issue
Feb 13, 2024
- #1 - zinc-collective#709 - For a #9 to leverage the behavior we described, we need a way to put tobias on the web. zinc-collective#709 are the equivalent of an "App" in the Convene world. - Note: `Gizmo` and `Furniture` are equivalent. We probably should finish zinc-collective#1472 - The migration change makes sure that ahttps://github.com//issues/4 is connected to #1
zspencer
added a commit
that referenced
this issue
Feb 13, 2024
- #1 - zinc-collective#709 - For a #9 to leverage the behavior we described, we need a way to put tobias on the web. zinc-collective#709 are the equivalent of an "App" in the Convene world. - Note: `Gizmo` and `Furniture` are equivalent. We probably should finish zinc-collective#1472 - The migration change makes sure that ahttps://github.com//issues/4 is connected to #1
zspencer
added a commit
that referenced
this issue
Feb 13, 2024
- #1 - zinc-collective#709 - For a #9 to leverage the behavior we described, we need a way to put tobias on the web. zinc-collective#709 are the equivalent of an "App" in the Convene world. - Note: `Gizmo` and `Furniture` are equivalent. We probably should finish zinc-collective#1472 - The migration change makes sure that ahttps://github.com//issues/4 is connected to #1
zspencer
added a commit
that referenced
this issue
Feb 27, 2024
- #1 - zinc-collective#709 - For a #9 to leverage the behavior we described, we need a way to put tobias on the web. zinc-collective#709 are the equivalent of an "App" in the Convene world. - Note: `Gizmo` and `Furniture` are equivalent. We probably should finish zinc-collective#1472 - The migration change makes sure that ahttps://github.com//issues/4 is connected to #1
zspencer
added a commit
that referenced
this issue
Feb 27, 2024
- #1 - zinc-collective#709 - For a #9 to leverage the behavior we described, we need a way to put tobias on the web. zinc-collective#709 are the equivalent of an "App" in the Convene world. - Note: `Gizmo` and `Furniture` are equivalent. We probably should finish zinc-collective#1472 - The migration change makes sure that ahttps://github.com//issues/4 is connected to #1
zspencer
added a commit
that referenced
this issue
Mar 25, 2024
- #11 I'm starting out by coding by wishful thinking, putting together the pieces of the pie that I can eat bite by bite. In this test, I'm using imagining there will be a Model called `Tobias::Payout`, which will be our computational entrance point into the [Issuing a Payout](#11) feature. I considered starting with a system test, which would have gone through the User Interface and tied together a bunch of different concepts; but I figured I would start with a `model` spec; so that I can stay focused on drawing the computer-facing side of the feature out before worrying too much about the human-facing bits; which I always find require a lot more thought for me. That said, a system test will be useful here at some point. The computational bits, on the other hand, feel pretty accesible. We want to create Payments for every Beneficiary of the appropriate amount, and store records of these Payments so we know who is supposed to get paid what. Here's a line-by-line play-by-play of this change: I'm using the `spec` folder to store executable examples of a feature. Because `Issuing Payout` is a feature for the [`TOBIAS` project](#1), I am storing it under `spec/tobias`. My choice of what to call the file (`payout_spec.rb` indicates that this spec will be for the `Payout` model. The `require "rails_helper"` line tells our testing framework to load all the code necessary to run a spec. The `describe Tobias::Payout do` line groups the examples nested within it as relating to the `Payout` model. The `describe "#issue"` line tells me that the `Payout` model will have a method named `issue`, and also creates a group of examples that describe how the `Payout#issue` method works. The `it "issues a Payment..." do` line describes one of the examples we we plan to use to confirm that the `Payout#issue` method works the way we hope it will. The test itself lives on the lines between `it "issues a Payment..." do` and the `end` that is aligned with the `it` The `payout = create(:tobias_payout, payout_amount_cents: 150_00) line says "create a database record of a `Tobias::Payout, and populate it's `payout_amount_cents` field with $150.00, and store a reference to it in the `payout` variable. The `beneficiaries = create_list(10, :tobias_beneficiary, trust: payout.trust)` line says create 10 `Tobias::Beneficiary` records in the database, and make sure their `trust` field is pointed at the same `Tobias::Trust` that our `payout` is pointing to. Store references to those in the `beneficiaries variable.` The `payout.issue` line executes the `Payout#issue` method that we are describing. The `beneficiaries.each do |beneficiary|` goes over every one of the newly created `Tobias::Beneficiary` records stored in the `beneficiaries` variable, expose each one as a variable named `beneficiary`, and execute the code between it and the next `end`. The `expect(beneficiaries.payments).to exist(amount_cents)` tells our example to let us know if there are no `Tobias::Payment` records in the database for one of the `beneficiaries`.
zspencer
added a commit
that referenced
this issue
Mar 25, 2024
- #1 - zinc-collective#709 - For a #9 to leverage the behavior we described, we need a way to put tobias on the web. zinc-collective#709 are the equivalent of an "App" in the Convene world. - Note: `Gizmo` and `Furniture` are equivalent. We probably should finish zinc-collective#1472 - The migration change makes sure that ahttps://github.com//issues/4 is connected to #1
zspencer
added a commit
that referenced
this issue
Mar 25, 2024
- #1 - zinc-collective#709 - For a #9 to leverage the behavior we described, we need a way to put tobias on the web. zinc-collective#709 are the equivalent of an "App" in the Convene world. - Note: `Gizmo` and `Furniture` are equivalent. We probably should finish zinc-collective#1472 - The migration change makes sure that ahttps://github.com//issues/4 is connected to #1
zspencer
added a commit
that referenced
this issue
Mar 25, 2024
- #1 - zinc-collective#709 - For a #9 to leverage the behavior we described, we need a way to put tobias on the web. zinc-collective#709 are the equivalent of an "App" in the Convene world. - Note: `Gizmo` and `Furniture` are equivalent. We probably should finish zinc-collective#1472 - The migration change makes sure that ahttps://github.com//issues/4 is connected to #1
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
TOBIAS: TOpical Basic Income Administration System #1 is a 🥔✨Gizmosconvene#709 for organizations that administer a basic-income 💰Trust#4 for a region or community.Fauxsonas
Benificiary#5Benificiary#5 receives a share of every Payout based on their EligibilityTreasurer#9Treasurer#9 monitors, records and reports on a Trust's financial informationFunder#6Funder#6 is anyone who contributes an 📈Asset#7 to the 💰Trust#4Use Cases
As a
TreasurerTobias: Registering aTrust#3Tobias: Issuing aPayout#11Funder::ContributionIncomeAsset::PurchaseAsset::SaleAs a
BeneficiaryTrustAs a
FunderDomain Models
Trust#4Payout#8Asset#7The text was updated successfully, but these errors were encountered: