##Opportunities
Future State: One of the objectives of BCDevExchange is to help facilitate connections and collaboration between people or organizations with needs, with other people or organizations that have solutions.
Could also be described as ‘unmet need’, ‘clearly definable, fully satisfiable want’, ‘problem that someone wants solved’, ‘solution opportunity’.
Something is published through BCDevExchange, letting others know that someone is looking for some kind of solution, and any parameters / restrictions around that. May or may not involve the exchange of money, but is expected to provide some kind of benefit for all parties involved.
Would be created in the context of an organization or individual, with a description and associated metadata. Will likely need some additional data, such as start and end date, eligibility restrictions, possible discussion history. Some or all of this may be supported by the use of GitHub Repos.
###Eligibility
Future State: Accounts registered on BCDevExchange will have some sort of attribute that impacts the types of tenders / contracts they are eligible to engage in (account level eligibility, inherited by all associated profiles). For example, someone may put out a tender with an eligibility level of Silver. Everyone is able to see the tender, but only people with a Silver or higher eligibility may enter into a contract. This could be a manually / user enforced rule (the owner would only select someone who meets the eligibility), or could be enforced by the system (disable buttons / functions for a tender if the account doesn’t meet the required eligibility). This attribute can change over time. Could be set by admin, or derived based on activity (system rules), or partially or completely derived by BCDevExchange peer input.
###Trust / Reputation
Future State: People and organizations involved in BCDevExchange have some sort of reputation or trust score, which is an indication to the rest of the community of how they are viewed by / within the community (account level reputation). This will likely be some amalgamation of activity within BCDevExchange, peer review / input, and authentication / verification of who the person or organization actually is. Could be a score (0 to 10, or without a limit), or could be a Y / N (Trusted Member or nothing) Could be tied into a multi attribute / badge system, providing a bit more of a 360 overview of the person’s activity. Or could be a component of that badge system, or parallel to it, like ‘Trusted Member’ or something like that.
###Authentication / Verification
Future State: People interacting with BCDevExchange may fall somewhere on the spectrum from ‘anonymous’ to ‘identified’, or somewhere in between. There is a level of interaction that may occur without an account (search, find, surveys), while more interactions are permitted with an account (post, share, add resources, create tender, payments, etc). Some of the interactions permitted with an account may only be enabled, or may be somewhat restricted, depending on the level of authentication / verification about the account in question. Verification needs further discussion, but for illustration purposes, could be tied into connecting BCDevExchange accounts to other verified accounts (such as IDIR), defining or performing validation against phone numbers, addresses, SIN, or paypal, or may involve processes external to the system (such as sending in a letter, having an interview, or signing something). The idea is to be able to indicate with a level of confidence that an account belongs to a specific, actual person (which some consider important when money is being exchanged).
###Response / Suggestion Future State: In response to an opportunity, people may submit ideas about how an issue could be solved, or a resource could be utilized, and may provide some of the details about how things would proceed (co-design, co-development, contract, payments, etc). The details of these responses may be evaluated against each other by the issuer of the tender.
Conversely, these responses may form more general input into the project, and may help shape the requirements themselves.
This seems like something that could be handled well through having an opportunity listed in the context of a project repo in GitHub, and using forking (and pull requests) or issues to submit ideas or suggestions.