I'm SO struggling for the name: Community Capitalism, a.k.a. ConsumerFunded.com, PFFS.cc, ccfmr.com, humbeep.com or Nonsofree.com, which are at the moment available. Whatever. Presently it's tomveatch.com/pffs, a mere personal subproject.

"This thing" will require some cloud infrastructure, including specifically at least a database, perhaps as complex as a medium-sized organization's accounting database.

We aim for its database table structure to be generic across projects and participants, so new projects and people can be added without restructuring the whole infrastructure.

Since I'm familiar with MySQL and know it to be robust to even large organizational purposes, let's use MySQL.

Now:

DB tables

Let there be tables as follows:

• Projects, Roles, Individuals, Roles-on-projects, Tasks, Teams, Bank, Donations, Payments, Logic (prerequisites, event, result) Descriptions, Plans, Project-trees, Histories.

Let there be table columns as follows (including unique ID for each table by default) (some of these are desiderata rather than column names, so this needs some work; also please review for redundancy).

• Projects: ProjectID, primary POC (an Individual's IID), Title (TextID), Abstract (TextID), Paper (DocumentID), ParentProjectID.

• Roles: RoleID, role as enum {idea specifier, PI/PM, lawyer, engineer, contractor, subcontractor, worker, donor, investor, closer, administrator, customer/user/beneficiary, public POC};

• Individuals: IID, Personal/Family/Business Names, Email Address, Mailing Address/St/City/State/Zip/Country, TaxID.

• Applications/Bids: BidID, from whom (IID), for what role (RoleID), in what project (ProjectID), to carry out what spec (SpecID) or task (TaskID), for what bid Amount, with what schedule (ScheduleID) with what acceptance criteria (LogicID).

• Assignments: (AssignmentID, ProjectID, RoleID, IID, TeamID, startDate, endDate.). Each row says a certain individual or team plays a certain role on a certain project starting and ending on dates of record (past) or planning (future). These are concrete descriptions of job assignment and responsibility to people.

• Roles-on-projects: AffiliateID, ProjectID, RoleID, Importance. Each row says a project contains a certain role with some importance level. These are abstract descriptions of need for roles to be played.

• Teams: some roles are carried out by teams, thus a TeamID associated with team members' IIDs, lets the TeamID be used. TeamMemberID, TeamID, IID, RoleID, joinDate leaveDate. Each row has a single team member. The multiple rows with the same TeamID are one team.

• Tasks: A task is a concrete assignment of who is doing something. Task ID, assigner role (RoleID & IID), assignee role (RoleID & IID), description (SpecID), status (enum {proposed, offered, agreed, future, ongoing, Milestone 1..120, finishing, done}), startDate, endDate.

• Specs: A spec is an abstraction, a statement of needs and work to be done but without who/when/where details entered. Tracking the facts is done in the Task table. Also, specs can be in a tree with parent specifications including subspecifications. The trees are implicit in the superspecs in the table; if a spec has no superspec then it's a separate tree.

  SpecID, ProjectID, superspec SpecID, BudgetAmount, BudgetRule, TextID, DocumentID (for description in brief or at length). status (enum {unspecified, draft, proposed, accepted, funded, tasked (tracks Tasks status passed the accepted phase), done (tracks Tasks status done}). Specs are used in milestone transitions and thus may have BeforeDescription, AfterDescription, as well as Criteria given in the details.

  A Project's budget can be built for each ProjectID from the specs attached to that project, each spec having its own budget amount and rule of interpretation.

  Considered having a plans table with project (under specs), task (under join tasks specs for a given project), milestones, orderings, release-triggers, doer, judger, final acceptance (all under Schedules and Milestones); those are all contained elsewhere, so we don't need a separate plans table.

• Schedule: A schedule is a sequence of milestones. ScheduleItemID, ScheduleID, sequence, MilestoneID. Each row is a single milestone on the schedule, ScheduleID is the same across multiple milestones in the schedule. ScheduleItemID is unique AUTO_INCREMENT in the table. Sequence enables ordering, as a numeric or at least sortable field to order the milestones which we assumed are fully orderable.

• Milestone: A milestone for a project enables knowing what it is (by its name), when it's complete (by its spec), who requests (Requester), rejects (Acceptor), or manages (Judge) acceptance (each by their roles), what are the costs and benefits of late/early performance, some structure enabling there to be a sequence of milestones with descriptions, triggering successor tasks or funds flow. MilestoneID, Name, SpecID, requestor RoleID Acceptor RoleID, Judge RoleID, StartDate, Duration, DaysEarly, EarlyReward, DaysLate, LatePenalty.

• Logic (prerequisites, event, result)
  E.g., business logic rules for what to do under what circumstances.
  E.g., with a project ongoing, reaches a milestone, triggers judgement/acceptance/rejection spiral then acceptance then payment release. Including release criteria for milestones.
  Or, when to add a manager, when to add a separate PR person, how much budget is required before spending some to make a better budget, etc.

• Texts: TextID, create-date, version number, creator IID, content (a short, standalone HTML5 utf-8 text snippet without JavaScript or CSS styling, <256B, to be displayed as < div id="$text_ID" > $content < / div > ). Texts are used as Project, Task, and Spec Titles and Abstracts.

• DocChunks: ChunkID, DocumentID, prev ID, succ ID, create-date, version number, creator IID, and content (long text documents are here broken up into page-size (2048B) chunks; appended without separator they are to be displayed as a text discussed above; HREF links supported to reference static external content.) Documents contain descriptions of as use case, features, benefits, infrastructure requirements, current budget, current plans, whatever is needed.

• ProjectTree is implicit in the above data tables. It is implemented with one-way pointers in the Projects table. Each ProjectID is a node in the tree; without parents it is at the top level. ProjectID 0 is the implied global parent. If daughters can't be built from the DB on the fly, then maybe a daughterProjects table would need to be made. Some placeholder project IDs are: Software, Medical research, Other research, Public Works. Maybe if a new project is not one of those then it needs a parent project to be specified.

• TX: a double entry financial transaction history: date, from account, to account, amount, currency, item, description, associated to ProjectID, SpecID, optional IID for donors and recipients, MilestoneID (for milestone-tagged donations and payments), subscription donations, etc.). (One should be able to roll this up from day one to sum up everything in each account.)
  • Accounts (each can be read of the tx history with its account name to make another redundant table of its own with a tx structure): enum {
    • payable,
    • receiveable,
    • cash on hand,
    • bank,
    • donations,
    • unreleased,
    • released,
    • paid,
    • reported,
    • taxes-payable,
    • taxes-paid,
    • inventory
    }

  A donation is a TX from donations to receiveables specifying amount, currency, date, donor's IID, project ID, spec ID for acceptance criterion for when the funds will be released.

  A payment is a TX from released to paid specifying similarly: amount, currency, recipient's IID, from ProjectID, to RoleID, upon milestone, relating to SpecID.

  ---

• CoWork communications. Thread ID, CoTask Title, from whom to what list of recipients, under what project and task and role triggering what milestones if any, text of message, previous-message-in-thread, relative date of reply expected. (Like Sprex Co-Work participants should be able to see each others' queues and demand reply so as to move work forward.)

Uses, UIs, Queries:

Pages

• With each role some set of user manual documented operations come authorized; the user manual should detect the user's authorized abilities and show those only. The manual could for example show how to modify the spec or adding a new spec in a given category.

• Each Role should have its approperiate dashboard components providing UX for carrying out its particular duties.
• RSU dashboard page: table of browsed projects history and similars by recency or depth, CoWork board, donations given, funds disbursed, docs (annual-monthly related activities report/1099 forms, ..), available actions: edit/SCRUD projects/specs/results, message POC or fellow project team or PI/PM or POC or Admin or all the project followers or IIDs listed as in any role on the project. CoWork UI. Project advancement steps and UI. etc.
• Top level menu of Login or RSU Dashboard, About, Team, Stories, Resources, Projects.
• Top level Home page The main public presentation or web ui will include besides general material a project tree, generated on the fly from the current database state. From the project-trees and projects tables the UI can build up an outline tree structure composed of organizing categories and titles of specifications.
• Project Tree Browser View. A browsing user, logged in, can select and see a node in the tree, can browse up down and sideways in the tree to see what's in there so far, and to read about the vision, how-to's, etc., can add nodes to the tree by giving a title and description.
• Admin dashboard. Add/edit any row of any table. Each of the above tables should have a SCRUD UI page, for adding rows to it (Search/Create/Read/Update/Delete), along the lines of ops/is/README.

  Some reporting code should run the SQL query and report information back to the admin, or perhaps other roles to be selected based on the query itself and its sensitivity, for example:

  • its financial and development status,

  • the constituents presently engaged,

  • the email discussion list(s) associated with the project,

  • etc.

  User Manual

  Actions for various users include:
  • Site admin/architect
    • Implement the database, operations, UI. That's me so far.
    • Review and implement proposed Project-Tree modifications.
  • Unregistered browser:
    • Browse the project tree, but not to see the flows and status.
    • Recieve public knowledge: software downloads, research summaries, papers, results, question answers.
    • Register for a login account with legal-name verification.
  • Registered site user
    • Email the POCs on any project. POCs should not get any comms from other than registered site users.
    • See the flows and status of projects
    • Initiate a donation process thereby becoming a donor.
    • Act as donor, idea specifier, bidder, etc.
  • Donors:
    • Changing donor anonymity status.
    • Defining a donation, including a project plus optionally a spec and milestone, a basis for release, and an amount.
    • Making a donation, which implements and tracks a money transfer to the bank account associated with a donation.
    • Approving/accepting a milestone transition request.
    • Rejecting a milestone transition request with the reason.
    • Reviewing previous donations each with their state.
    • Annual donations summary for tax purposes (1099?).
  • Idea specifier
    • add a subproject to the tree as private draft, edit title, abstract, documents and spec.
    • update project+spec status from draft to proposed
  • Reviewers
    • access proposed project+spec, accept or give feedback, propose tree structure changes as appropriate.
  • Bidder
    • Submit bids for project+spec with amount and milestones agreed
  • PI/PM
  • Worker: lawyer, engineer, contractor, subcontractor, worker,
    • Recieve and accept or reject assignments proposed.
    • Request spec modifications (change-orders) with an offered price.

    • Lawyer
      • subprojects or specs might include legal defense, including evaluation of vulnerability, feedback for how to behave for self-protection, and legal actions from letters to lawsuits. Then the lawyer role is associated with that spec, and escalating project requirements may drive proposal/acceptance/work/milestone sequences as for other workers.
    • Engineer
    • contractor, subcontractor,
    • worker
  • PI/PM
    • This is the name on the project as the responsible party for implementation.
    • Add roles to specs. Assign roles to teams and individuals.
    • Harass and negotiate with the workers for movement and timeliness.
    • Remove teams and/or individuals from a project+spec+role (endDate)
    • Approve payments to staff.
  • Investor
    • An investor is simply a donor whose donations are early enough in the stream of donations for a project that they participate in the returns function. The returns function is a declining exponential return rate applied to each donated dollar in order of what hit the bank account soonest, with the purpose of motivatingq early adopters/investors/donors to donate by giving them a fraction of certain proceeds. Investment optimization might be for more returns based on larger project costs, or for more returns based on more social impact. Since we are not sure how to measure the latter, we'll presently give the Investors a declining exponential return for each dollar invested based on total project size, and/or funds raised and/or funds expended, and/or funds over requirement raised. Yes, indeed, a better criterion might be total social impact but that might be hard to measure, even if it would help to catch the low-hanging fruit of greater good for society. Still we want to have motivations aligned also for the system itself, which is intended to provide a lot of employment, to do a lot of work and move a lot of economic value through it.

      The admin and others can be matching investors.

      Become a project investor by simply becoming a donor but early enough to participate in the returns schedule.

      System investors could be matching investors by specifying that their money can follow the other money perhaps within a domain of projects (by donating onto a node higher the project tree) or by the investor donating early into specific projects. Projects may evolve via split to become first the now attainable and second the future desired, so as to enable shipping early and often for the purpose of accelerating user feedback and donor outreach.

  • Public POC
    • This is a communications role, not a role for moving projects forward.
    • Project communications forwarded here.
    • Responsible for press releases, public relations, adding excitement and utility.
    donor, investor, closer, administrator, customer/user/beneficiary};

    	Your thoughts?
    Name+:
    Email*:	(will not be shared or abused)
    Comment:
    	Feedback is welcome.