2 |
3 | ---
4 | [Back to Discussion Index](../discussion_index.md)
5 |
6 |
7 | 
8 |
--------------------------------------------------------------------------------
/CONTRIBUTING.md:
--------------------------------------------------------------------------------
1 | ## How to contribute
2 | Government employees, public and members of the private sector are encouraged to contribute to the repository by **forking and submitting a pull request**.
3 |
4 | (If you are new to GitHub, you might start with a [basic tutorial](https://help.github.com/articles/set-up-git) and check out a more detailed guide to [pull requests](https://help.github.com/articles/using-pull-requests/).)
5 |
6 | Pull requests will be evaluated by the repository guardians on a schedule and if deemed beneficial will be committed to the master.
7 |
8 | All contributors retain the original copyright to their stuff, but by contributing to this project, you grant a world-wide, royalty-free, perpetual, irrevocable, non-exclusive, transferable license to all users **under the terms of the license under which this project is distributed.**
9 |
10 |
11 |
--------------------------------------------------------------------------------
/wireframes/release-1/README.md:
--------------------------------------------------------------------------------
1 |
2 |
3 | ---
4 |
5 | This folder is intended to be used to circulate draft wireframes.
6 |
7 | .PNG files are images viewable by everyone, and are referenced by some of the .md files in docs/discussion
8 |
9 | .bmml files are Balsamiq files, which can be forked / edited by those with access to Balsamiq (the wireframe tool used by some members of the BCDevExchange dev team). https://balsamiq.com/
10 |
11 | We'd love to get your feedback on any of these wireframes. Soon you'll be able to sign up with [BCDevExchange](http://bcdevexchange.org/) to access the labs, and see some of these actually being developed.
12 |
13 |
14 |
--------------------------------------------------------------------------------
/discussion_index.md:
--------------------------------------------------------------------------------
1 | Index for Discussion folder content.
2 |
3 | ---
4 |
5 | [Discussion Index](discussion_index.md)
6 | * [BC Developers' Exchange Overview](discussion/BCDevExchangeIntroductionv3kam.pdf)
7 | * [Accounts](discussion/accounts.md)
8 | * [Organizations](discussion/organizations.md)
9 | * [Opportunities](discussion/opportunities.md)
10 | * [Profiles](discussion/profiles.md)
11 | * [Interests](discussion/interests.md)
12 | * [LinkedIn and Profiles](discussion/linkedin.md)
13 | * [Projects](discussion/projects.md)
14 | * [Project States](discussion/projectstates.md)
15 | * [Project Backlogs](discussion/backlogs.md)
16 | * [Projects in GitHub](discussion/github.md)
17 | * [Programs](discussion/programs.md)
18 | * [Resources](discussion/resources.md)
19 | * [Resources in GitHub](discussion/github.md)
20 | * [State Labels](discussion/statelabels.md)
21 | * [Lab](discussion/lab.md)
22 |
23 | Architecture
24 | * [Design Principles](discussion/principles.md)
25 | * [Architecture Document](discussion/architecture.md)
26 | * [Developer Registration](discussion/devregistration.md)
27 | * [Domain Model](discussion/domainmodel.md)
28 |
--------------------------------------------------------------------------------
/discussion/linkedin.md:
--------------------------------------------------------------------------------
1 |
2 |
3 | ---
4 | [Back to Discussion Index](../discussion_index.md)
5 |
6 |
7 | ##LinkedIn for Profiles
8 |
9 | **Release 1** The LinkedIn API is somewhat limited in how it can be used (both in breadth of records being queried and throttling). It’s being proposed that LinkedIn profiles registered with BCDevExchange be regularly queried and cached on BCDevExchange, which can then be queried by users in real time. This is intended to prevent permanently storing this data, as it will persist temporarily (albeit repeatedly), and will help alleviate some architectural and performance concerns anticipated by using the LinkedIn API. Token used to query LinkedIn profiles via the LinkedIn API are only valid for 60 days. Users will have to be made aware of this limitation, and that they will only be returned by queries for 60 days following their last log in to BCDevExchange.
10 |
--------------------------------------------------------------------------------
/discussion/principles.md:
--------------------------------------------------------------------------------
1 | 
2 |
3 | ---
4 | [Back to Discussion Index](../discussion_index.md)
5 |
6 |
7 | # Our Design Principles...
8 | ...were created as a group during Sprint 4 and have proved very useful in guiding the development team towards innovative solutions.
9 |
2 |
3 | ---
4 | [Back to Discussion Index](../discussion_index.md)
5 |
6 |
7 | ##Interests
8 |
9 | **Future State:** For each [profile](profiles.md), the user can define what the profile is interested in. This involved identifying one or more combinations of tags (using the same pool of Resource and Project tags) to create interests. For example, a user could identify two different interests for their Individual profile of [datasets, environment, forestry, animals, bears] and [APIs, transactional, environment], and other types of interests defined for their other profiles. These defined interests can be used as automatic filter / search criteria when searching for Resources, or drive optional notification emails alerting the user to new Resources similar to their interests. When aggregated across accounts / profiles, these could be used to identify what sorts of things the BCDevExchange community as a whole is interested in obtaining, and help inform Resource providers of what sort of stuff is wanted / needed.
10 |
--------------------------------------------------------------------------------
/discussion/backlogs.md:
--------------------------------------------------------------------------------
1 |
2 |
3 | ---
4 | [Back to Discussion Index](../discussion_index.md)
5 |
6 | ###Project Backlogs
7 |
8 | **Future Release:** A backlog is a list of activities, ideas, features, or enhancements being considered for a Project. It’s proposed that the GitHub Issues functionality be used to support backlogs for Projects located in GitHub. The issue list associated with a project repo would hold its backlog.
9 |
10 | If using GitHub issues to support the display of a project backlog, it may be important to consider ways to filter or flag which issues are displayed as part of the backlog. It's suggested that issue labels (such as 'backlog-issue', 'backlog-feature' or 'backlog-opportunity', be used to indicate which issues should be visible as part of a public / BCDevExchange facing project backlog. Issues that are not labelled using this convention would not display as part of the public / BCDevExchange project backlog, and could be used to track internal issues, discussions, questions or other issues relevant to the repo in question.
11 |
--------------------------------------------------------------------------------
/discussion/statelabels.md:
--------------------------------------------------------------------------------
1 |
2 |
3 | ---
4 | [Back to Discussion Index](../discussion_index.md)
5 |
6 |
7 | ##State Labels
8 |
9 | **Release 1:** A visual identifier will be used to identify the current state for all elements within and supported by the BCDevExchange. This will include Projects and Resources, as well as functionality and pages within the BCDevExchange website. Below are prototype images that may be used to identify the current state of each element, with terminology corresponding to the proposed [Project States](projectstates.md).
10 |
11 | ##Labels for Web Pages / Content
12 | __Badges__
13 |
14 | **Release 1:** BCDevExchange content located within GitHub will be labelled with a similar convention as the above Project States, but utilize the following badge system.
15 |
16 |
17 |
18 | 
19 |
20 |
21 |
22 |
--------------------------------------------------------------------------------
/discussion/organizations.md:
--------------------------------------------------------------------------------
1 |
2 |
3 | ---
4 | [Back to Discussion Index](../discussion_index.md)
5 |
6 |
7 | ##Organizations
8 |
9 | A BCDevExchange Organization is an entity that exists parallel to profiles. Where account profiles are a representation of an individual’s interactions with BCDevExchange, an Organization is a representation of a group’s interactions with BCDevExchange.
10 |
11 | **Release 1:** Organizations will not exist as distinct entities. There is a parallel / similar concept in GitHub, which may be able to be leveraged to some degree, such as being displayed on BCDevExchange as the owner of a Repo registered by one of the GitHub Organization’s owner profiles.
12 |
13 | **Future State:** An Organization can be created by any user on BCDevExchange. Creating an Organization automatically creates a new profile associated to the account of the user who created it, giving this user the privileges to maintain a profile specific to the newly created Organization. The owner of an Organization may invite other people to join their Organization, and may maintain their privileges as they pertain to that Organization, including identifying other owners.
14 |
15 | An Organization has its own description and Organization specific profile, which track things like Org specific contact information, payment information, resources, projects, descriptions, and logos. Members of an Organization may perform actions on behalf of that Org (such as listing new resources), by selecting the Org profile when signing in. Members of an Org can view a feed of organization specific activity, so they can stay up to date with what their co-workers / peers have been up to.
16 |
17 | In addition to being invited into an Org, users can proactively request an invite to an Org, which can then be accepted by members of the Org who have appropriate privileges within that Org.
18 |
19 | Could consider creating an Organization of BCDevExchange within the BCDevExchange site framework, allowing for different people to get involved and have input into projects belonging to the BCDevExchange (very meta).
20 |
--------------------------------------------------------------------------------
/discussion/profiles.md:
--------------------------------------------------------------------------------
1 |
2 |
3 | ---
4 | [Back to Discussion Index](../discussion_index.md)
5 |
6 |
7 | ##Profiles
8 |
9 | **Release 1:** A tool is being considered to allow users to search profiles based on certain criteria – such as credentials, skills, or accreditation – to allow users to find people instead of Resources or Projects via the exchange. Although the concept of Profiles will develop over time, the current proposed approach is for the development team to investigate ways to integrate with LinkedIn to use skills, credentials, and experience information that already exists, so users don’t have to maintain multiple skills profiles (leveraging what’s in LinkedIn), which would be made available to the BCDevExchange via registering / signing up with a LinkedIn account.
10 |
11 | **Future State:** All BCDevExchange users have at least one profile defaulted to their account, the Individual profile. Accounts may have additional profiles defined against them, each of which will correspond to membership in a BCDevExchange Organization. Each profile associated with an account is maintained separately, and may include details such as contact information, payment information, owned resources, resource interests, certifications / privileges, skills, and project history (all under discussion / to be determined).
12 |
13 | All Resources added to the BCDevExchange are done so in the context of a signed in user, and are created in the context of their currently selected profile. If the current profile is Individual, then the Resource is associated with and owned by that specific person, and Resource specific privileges (such as performing updates) are owned by that profile. If the current profile is an Organization specific profile, then the Resource is associated with and owned by that Organization, and any member of that Organization (with the appropriate Organization privileges) can maintain that Resource.
14 |
15 | ###People Wanted
16 | **Release 1** One of the requirements identified is the ability to post a ‘want ad’ sort of element, to try and find a member of BCDevExchange with certain skills or interests. It’s proposed that the GitHub Issues functionality (in the context of a Repo identifying the project in question – possibly in an Inspiration or Exploration state) be used to support this sort of posting. The issue could be labelled with something like ‘help wanted’, and be picked up through a search function on BCDevExchange.
17 |
18 | ###Mockup
19 | 
20 |
--------------------------------------------------------------------------------
/spikes/Spike30-Meeting-Notes-2015-09-22.md:
--------------------------------------------------------------------------------
1 | #API Owner Engagement Level
2 | (service scenarios using BCdevExchange):
3 | ----
4 | ---
5 |
6 | | Engagement Level in Ascending Order | 9 |Self Serviceable? | 10 |Provider Activity | 11 |Feature Needed | 12 |
|---|---|---|---|
| Advertisement Only | 15 |Yes | 16 |supply swagger URL | 17 |API explorer; search; code snippet; |
18 |
| Extended Channel | 21 |Yes | 22 |compose swagger | 23 |+ API gateway; swagger composer |
24 |
| Exclusive Channel (Migrate Domain) |
27 | Yes | 28 |+ supply SSL cert files change existing DNS to a CNAME |
29 | + dynamic SSL cert selector | 30 |
| Simple hosted repo with CRUD operation | 33 |Yes | 34 |Create data model via GUI | 35 |+ modeler | 36 |
| Complex hosted repo (custom code to transform data) |
39 | No | 40 |+ supply custom code via PR | 41 |GitHub! | 42 |
2 |
3 | ---
4 | [Back to Discussion Index](../discussion_index.md)
5 |
6 | ## Accounts
7 | BCDevExchange will support the creation and maintenance of user accounts.
8 |
9 | **Release 1:** We are exploring the idea of creating BCDevExchange accounts via existing GitHub accounts and LinkedIn accounts for context and authentication. Users will be able to create an initial BCDevExchange account through either of these, and then **(Future Release)** link the other one after the fact (for example, sign up with GitHub, then subsequently tie in the LinkedIn account). Once associated with BCDevExchange, users can then log in using either GitHub or LinkedIn. Subsequent releases may allow the use of additional identity providers and authentication services. Upon the creation of the BCDevExchange account, the user will have a single Profile associated with it (their individual profile).
10 |
11 | **Future State:** Each account will reflect a single person / user, but can have multiple associated profiles to indicate the different contexts from which the person is interacting with BCDevExchange. For example, a BCDevExchange account may have a single Individual profile, as well as multiple Organization specific profiles (each derived from their association with an Organization). Certain core information is shared between all profiles, and maintained against the core account itself, while other information is profile specific, and not shared between profiles. These concepts and data relationships are expected to evolve over time as functionality is rolled out.
12 |
13 | Users need to be able to sign in and sign out of BCDevExchange. When signing in, they should be prompted to define the context of their current session, allowing them to choose between the different profiles associated with their account. This sign in context will impact how they interact with features within BCDevExchange, such as defaulting the owner of newly created resources, or what sort of profile maintenance functions they have access to. Users should be able to swap contexts within a signed in session, without having to first sign out.
14 |
15 | ###Mockups
16 |
17 | The sign up process is expected to be handled either through an existing GitHub account or an existing LinkedIn account. A minimum amount of information is intended to be stored by BCDevExchange (just enough to allow subsequent log ins). Sign Up using GitHub is expected to be available in **Release 1**, while Sign Up via LinkedIn may be available only in a **Future Release**.
18 |
19 | 
20 |
21 | Linking repos is being considered for a future release, allowing members of BCDevExchange to self register and maintain projects and resources (via GitHub repos).
22 |
23 | 
24 |
25 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 |
2 |
3 | ##Our Active Work Items: [](https://waffle.io/BCDevExchange/Our-Project-Docs)
4 | [](https://gitter.im/BCDevExchange/Our-Project-Docs?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge "Please do not provide any personal information or third-party personal information (ie. talk about others) in your use of the Gitter application. Any information you choose to provide will not be in the custody or control of the Ministry of Advanced Education. For more information, please see the Privacy Policy of Gitter.")
5 | # docs
6 |
7 |
8 | BCDevExchange artefacts including documents, templates, a wiki (deprecated) and other useful things like output from tech spikes. If you'd like to participate - feel free to chat with us on Gitter, comment or add an issue, we'd love to hear from you.
9 |
10 | 
– Used to identify a concept or idea that is being explored. In this state, there are no considerations towards IP, money / funding, or licenses, and is just an investigation of a topic or idea, often in an open and collaborative way.
2 |
3 | ---
4 |
5 | # Welcome to the BCDevExchange discussion folder!
6 |
7 | This is where we are sharing the concepts and entities that are being being considered to build the framework for BCDevExchange.org. Most of the content in here is continuing to be defined and refined, and should be considered [Inspiration State](projectstates.md).
8 |
9 | If creating a page, please consider adding an Inspiration Badge, by adding the below code (adds Inspiration Badge with alt text description).
10 |
11 | ## Inspiration Badge code.
12 |
13 |
14 |
15 |
16 |
17 | ## Exploration Badge code.
18 |
19 |
20 |
21 |
22 |
23 | ## Delivery Badge code.
24 |
25 |
26 |
27 |
28 |
--------------------------------------------------------------------------------
/discussion/labs.md:
--------------------------------------------------------------------------------
1 |
2 |
3 | ---
4 | [Back to Discussion Index](../discussion_index.md)
5 |
6 | #Lab
7 |
8 | *Note: Labs should not be confused with current state lab.bcdevexchang.org as of March 2015*
9 |
10 | **Release 1:** In support of the principles of open development and co-creation, it is proposed that the BCDevExchange website be enhanced to include a "labs" space. This labs area will allow members of the BCDevExchange to showcase and share functionality and content that is in the Inspiration and Exploration states, while providing some protection and coverage to those sharing in the lab. The lab, and its contents, will all be clearly labeled as being in the lab, with disclaimers and descriptions of what that means.
11 |
12 | In addition to providing a location and framework for the BCDevExchange to share ideas, concepts, functionality, and content being considered for the BCDevExchange.org itself, the lab is also intended to support other, non-BCDevExchange projects, giving them a safe place to evolve and share.
13 |
14 | The lab functionality will only be available to users who have signed up with the BCDevExchange. In early days, the lab area may be further limited to select users or groups as the lab idea is further defined and refined. Users should be able to navigate between BCDevExchange and its lab area after logging in. When entering the Lab area, the site will provide a message warning to the user that they are entering the lab, provide any required disclaimers, an overview of the state concepts used in the lab, and possibly a ‘what’s new in the lab’ summary.
15 |
16 | When interacting with any project within the BCDevExchange lab, the current state of each project, page, resource, or function should be clearly displayed to the user at all times, through the display of the appropriate state tag (Inspiration, Exploration, or Delivery).
17 |
18 | ##Proposed Solution
19 |
20 | A very distinct Lab area will be created. The lab area exists separate to BCDevExchange.org, though is only accessible to users who are signed up and logged in to BCDevExchange. This lab area will provide an area where many different projects / code / applications can exist, including a lab version of BCDevExchage.org. The lab will provide some tools to users, such as an instance of CKAN (for catalogue / data sharing functionality), and WSO2 (for API Management / Console functionality).
21 |
22 | ###User story
23 |
24 | 1. User navigates to bcdevexchange.org
25 | 2. User selects top level nav item 'Labs'
26 | 3. User sees a lab landing page listing all labs
27 |
28 | The existing BCDevExchange.org app provides a use-case to justify the need for a lab space. Additional user stories will be gathered to help shape the evolution of the lab space / concept.
29 |
30 | ###Mockup
31 |
32 | Several ideas are being considered for how the Lab concept will be handled. The below mockup shows a lab landing page, accessed via BCDevExchange, which would provide links to different things in the lab.
33 |
34 | 
35 |
36 |
37 |
--------------------------------------------------------------------------------
/discussion/github.md:
--------------------------------------------------------------------------------
1 |
2 |
3 | ---
4 | [Back to Discussion Index](../discussion_index.md)
5 |
6 |
7 | ##GitHub as a Data Source
8 |
9 | To support the principle of relying on external data, it is proposed that GitHub be used as a source of data for BCDevExchange.org. Some proposed ideas are discussed below.
10 |
11 | **Release 1:** To help avoid having to build out a backend or store data on BCDevExchange, it’s proposed that we utilize GitHub as a ‘back end’ / database. This could theoretically be used to store information for any of the elements discussed in this document (Profiles, Organizations, Resources, Interests, or Projects), but would probably be initially used just for [Resources](resources.md) and [Projects](projects.md).
12 |
13 | An idea being discussed is tagging a Repo’s readme.md with an identifier flagging it as a Project (BCDevExchange-Project) or a Resource (BCDevExchange-Resource), and having BCDevExchange search functionality return these as part of relevant queries. Some sort of structure within a Project Repo may also be useful for displaying a Project backlog to users via BCDevExchange, such as an associated issues list, which can be retrieved by BCDevExchange post query.
14 |
15 | To become available for search by BCDevExchange, a repo would need to be registered by a user who has created an account with BCDevExchange via an existing GitHub account.
16 |
17 | 1. Register with BCDevExchange with a GitHub account
18 | 2. BCDevExchange pulls and displays a list of GitHub Repos associated to the account (those associated directly with the account, and those associated with associated Organizations where the account has an Owner role)
19 | 3. For each Repo returned, the user can select a desired State (Research, Discovery, Delivery), and Type (Resource, Project, possibly others)
20 | 4. An Activate button (or other function) will display for each displayed Repo. Pressing this button will initiate the following automated process (done through GitHub / GitHub APIs) -
21 | 1. BCDevExchange Organization forks the Readme.md from the selected Repo
22 | 2. Appends the Readme.md with a BCDevExchange identifier, state, type, and URLs for relevant badges
23 | 3. A pull request sent to the Repo owner
24 | 5. Once the pull request is accepted, then the Repo will be returned by calls to the GitHub API from the BCDevExchange search functionality
25 |
26 | GitHub has an API available for querying its repos and files. There are some limitations that require an account name or repo name to be identified when using the API. This would require users to register with BCDevExchange.org with a GitHub account (thereby registering their GitHub account with BCDevExchange), which can then be used when calling the GitHub API and querying its data.
27 |
28 | ###Conversations
29 |
30 | **Future State:** GitHub supports Repo specific Wikis and Issue reporting / tracking. These existing tools are being considered as mechanisms to support conversations, discussions, and feedback on Projects or Resources shared on BCDevExchange through GitHub. Projects and Resources stemming from other locations (such as BCDC) would require different tools to support discussions or feedback. As mentioned previously, issue lists can be used to store and track a project backlog.
31 |
32 | ###Organizations
33 |
34 | **Future State:** [Organizations](organizations.md) maintained in GitHub could be identified through the presence of an associated .md (with naming convention or content) or specific keywords in their description, and used to populate search results from BCDevExchange.org.
35 |
--------------------------------------------------------------------------------
/discussion/resources.md:
--------------------------------------------------------------------------------
1 |
2 |
3 | ---
4 | [Back to Discussion Index](../discussion_index.md)
5 |
6 |
7 | ##Resources
8 |
9 | **Release 1:** BCDevExchange will host an exchange allowing users to post Resources visible to other users. Resources are intended to reflect actual things, usually digital resources, such as code, APIs, applications, and datasets. We are hoping to create a search function on BCDevExchange that looks at both a) GitHub repos and b) registered catalogues, and display things identified as resources (see below Future State 2 and 3). Intention is to delay any implementation of a database / significant back end with stored data on BCDevExchange, and instead rely on external data, functions, and services.
10 |
11 | **Future State:** All Resources are owned by either an Individual profile (when created or registered in the context of an Individual profile) or an Organization (when created or registered in the context of an Organization specific profile).
12 |
13 | It’s proposed that Resources can be added to the Exchange in several different ways –
14 |
15 | **1 The ‘Fat Finger’ method:** manually typing a Resource into BCDevExchange.
16 |
17 | **2 Registering a catalogue:** providing the details and access information for a compatible catalogue, which exposes an API that can be called by BCDevExchange to harvest its contents in a real time manner.
18 |
19 | **3 Registering a GitHub repo:** providing the details and location of a repo or file within GitHub containing Resources or their details, which can then be harvested by BCDevExchange. This could also be done through adding a template, file, or other identifier to a repo in GitHub, flagging that repo in a unique way (such as /#BCDevExchange) which is used by BCDevExchange to identify and scrape the data in response to a search. Not sure if a Repo would be one Resource, or would contain a list of resources.
20 |
21 | A Resource is identified via a title, description, and possibly multiple metadata tags (which may include things like applicable licenses). Depending on the manner in which the Resource was added to BCDevExchange, the Resource may be updatable through the BCDevExchange functionality, or by modifying the source location (catalogue or GitHub repo readme.md).
22 |
23 | BCDevExchange search functionality will allow users to search on and filter Resources by a variety of search parameters. After searching for a Resource, users are able to select and view the details of a Resource, including linked content and sources, as well as other Resources similar to the selected Resource (based on similar metadata tags and users having followed it). Users may flag a Resource to follow it, in the context of their current profile, and receive notifications regarding changes to that Resource.
24 |
25 | ###Resource Metadata (Tags)
26 |
27 | **Release 1:** Depending on the source of the resource being displayed in BCDevExchange, it may be possible to filter, retrieve, and display tags already associated with the resource. For example, BCDC already has a concept of keywords that seems functionality equivalent to tags, while GitHub does not have a clear parallel (though it could be facilitated through storing resources in a structured document, text appended to the Readme.md, badges, or something like that).
28 |
29 | **Future State:** As BCDevExchange does not have control over how users may create and define Resources, it is possible that the Resources being defined are defined at very different levels of granularity or using various terms or descriptions. To accommodate a wide range of definitions and descriptors, Resources will be described using metadata tags. When describing a resource, users can type in whatever value they want as a tag, with the interface prompting the user with existing metadata tags that are similar to existing metadata tags.
30 |
31 | ###Mockup
32 | 
33 |
34 |
--------------------------------------------------------------------------------
/discussion/opportunities.md:
--------------------------------------------------------------------------------
1 |
2 |
3 | ---
4 | [Back to Discussion Index](../discussion_index.md)
5 |
6 |
7 | ##Opportunities
8 |
9 | **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.
10 |
11 | Could also be described as ‘unmet need’, ‘clearly definable, fully satisfiable want’, ‘problem that someone wants solved’, ‘solution opportunity’.
12 |
13 | 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.
14 |
15 | 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.
16 |
17 | ###Eligibility
18 |
19 | **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.
20 |
21 | ###Trust / Reputation
22 |
23 | **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)
24 | 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.
25 |
26 | ###Authentication / Verification
27 |
28 | **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).
29 |
30 | ###Response / Suggestion
31 | **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.
32 |
33 | Conversely, these responses may form more general input into the project, and may help shape the requirements themselves.
34 |
35 | 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.
36 |
--------------------------------------------------------------------------------
/discussion/projectstates.md:
--------------------------------------------------------------------------------
1 | 
– Used to identify a concept or idea that is being explored. In this state, there are no considerations towards IP, money / funding, or licenses, and is just an investigation of a topic or idea, often in an open and collaborative way.
2 |
3 | ---
4 | [Back to Discussion Index](../discussion_index.md)
5 |
6 |
7 | ##Project States
8 |
9 | **Release 1:** Each project has a current state / status, which is intended to give a rough indication of where the project is at, which are currently conceived as Research, Discovery, or Delivery. The project state / status will be prominently displayed in the user interface of the BCDevExchange website. See [State Labels](statelabels.md) for examples.
10 |
11 |
12 | – Used to identify a concept or idea that is being explored. In this state, there are no considerations towards IP, money / funding, or licenses, and is just an investigation of a topic or idea, often in an open and collaborative way.
13 |
14 | 
– Used to identify something that is in the process of being built, and can be interacted with in some way, though usually in the context of a lab, trial, or test. May have disclaimers regarding use, and may be temporary in nature.
15 |
16 | 
– Used to identify something that has been built out and in alpha, beta, or production, and can actually be used in some manner. Suggests some level of permanency and support for the product.
17 |
18 | The benefits of this proposed model are to:
19 |
20 | 1. Identify what category something falls into, for quick labelling / communication reasons
21 |
22 | 2. Use consistent language and labels to help create a framework for guiding developers in their projects
23 |
24 | 3. Help make things safer and more orderly for people using the model, as guidelines and disclaimers can be developed and associated based on their current state in the model
25 |
26 | 4. Provide a (very) high level SDLC (though projects may move from one state to another freely), that can be used to help communicate the current state of a resource or project
27 |
28 | 5. Let people know what others are working on, to prevent duplicate effort, or to gain collaborators, elicit input, or increase awareness
29 |
30 | **Future State:** Changes in a project status could be announced on BCDevExchange main page to help raise awareness.
31 |
32 | ###BCDevExchange as a Project
33 |
34 | **Release 1:** This idea of a Project State / Status will be applied to aspects of BCDevExchange itself, and used to label ideas and functionality that are on the roadmap / backlog for the website itself. In a way, the development activities for BCDevExchange would consume and be supported by the framework that BCDevExchange is trying to create and facilitate.
35 |
36 | In support of the principles of open development and co-creation, it is proposed that the BCDevExchange website be enhanced to not only include functionality and content in the Delivery state, but also allow for the inclusion and sharing of functionality and content that is in the Exploration state (and possibly even the Inspiration state in some cases, such as content). Please see the [Lab](lab.md) page for more details.
37 |
38 | **Future State:** In addition to analytics, we are exploring the idea of a ‘self identification’ process, which will increase the value of analytics data. The idea is to allow users to select the context in which they are interacting with the BCDevExchange (such as Entrepreneur, Developer, or Resource Provider, titles going through initial research and may change). It is thought that this will help guide the development team in creating navigation that provides the most value to future users. For example, users who identify as Developers may be more likely to want to search for Contract Opportunities, while those who identify as Entrepreneurs may be more likely to want to search for Unmet Business Needs (or whatever).
39 |
--------------------------------------------------------------------------------
/discussion/architecture.md:
--------------------------------------------------------------------------------
1 |
2 |
3 | ---
4 | [Back to Discussion Index](../discussion_index.md)
5 |
6 | The contents of this page were taken from an architecture document produced in February, 2015.
7 |
8 | ----
9 | ###Purpose
10 |
11 | To communicate ideas about target solutions. In this document we will describe the solutions for the BC Developers’ Exchange project. The solution spans from the BC Developers’ Exchange to BC Government components. Why? Because, the project needs to know where we are going and if it’s the right thing to build.
12 |
13 | ###Read Time
14 |
15 | 10-30 minutes
16 |
17 | ###Process
18 |
19 | **Where did all this come from?**
20 | This is the result and ongoing process of listening to the product owners, subject matter experts and user groups.
21 |
22 | **What’s next?**
23 | This is not the first iteration of BC Developers’ Exchange, nor the last. This is [Discovery](projectstates.md).
24 |
25 | ###Who's who in the zoo and what do they do?
26 |
27 | There are three major types of players in the BC Developers’ Exchange domain fostering a thriving technology community. First, the providers have resources and collateral. BC Government is a major provider, but so too is all of BC’s broader public sector including crown corps, agencies and municipalities. Providers collaborate with and need services from developers. Second, developers need resources to invent new business. And third, what is BC Developers’ Exchange doing? It connects providers with developers in channels for research, discovery and delivery.
28 |
29 | 
30 |
31 | ###What exactly does BCDevExchange do?
32 |
33 | It’s a safe place for providers to share collateral like templates and guides. It’s a simplified description of government digital resources. More interestingly, it’s a place for providers to request services from developers. Developers and providers alike can manage their profiles including certifications. This solution is based on modern technologies and cloud services, but more on that later…
34 |
35 | 
36 |
37 | ###What does BC Government do in relationship to BCDevExchange?
38 |
39 | As mentioned earlier, BC Government is a major provider to BC Developers’ Exchange. Moreover, it’s where the BC Developers’ Exchange concept was born and fostered. In this diagram, we illustrate BC Government’s role as a provider. We envision other providers could follow similar models but are not obligated to. On the technology front, BC Government’s solution is a blend of GitHub, CKAN, WSO2 API Manager, web sites/app, and of course, BC Developers’ Exchange as a publisher and identity provider.
40 |
41 | 
42 |
43 | ###How are resources populated in BCDevExchange?
44 |
45 | The BC Developers’ Exchange has the exchange full of digital resources metadata. How does that metadata get into the BC Developers’ Exchange? Good old fashioned typing first of all. Not everyone is going to have fancy integrations or the volume to justify it. For the providers with catalogues that have APIs, the BC Developers’ Exchange can pull in the data. And, once the BC Developers’ Exchange is the place to be, people can push it to us.
46 |
47 | 
48 |
49 | ###How are existing resources discovered and consumed?
50 |
51 | The BC Developers’ Exchange, providers catalogues and API Managers… how does this all work? The BC Developers’ Exchange is likely the starting point. It will have digital resources, not all the gory details, but enough to stimulate developers creatively or to think that this will work for their needs. It is the responsibility of the API provider to have a catalogue or landing page to describe the API in further detail. Some API providers may have fancy API Management systems, in which case they get nice formatted docs and even API consoles.
52 |
53 | 
54 |
55 | ###How does API Management work?
56 |
57 | Wait a second, what is an API Manager? When you’re a large organization, dealing with dozens if not hundreds of APIs fragmented across many business units is a poor user experience for developers (aka API consumers). Not to mention, duplication of effort to implement the cross cutting concerns that API providers have such as: access control (API key management), monitoring, throttling, displaying specs, API consoles, etc. This diagram shows a typical example of how API Managers work.
58 |
59 | 
60 |
61 | ###How do CKAN (BCDC) and WSO2 API Manager integrate?
62 |
63 | Some providers won’t have fancy catalogues and API managers. All API Management products have their own catalogue features. In the case of BC Government, they have a super catalogue system already called BCDC (based on CKAN). And, its scope is broader than just APIs. In makes sense to use it. The catalogue doesn’t have API manager features we need though. Here’s how we can have our cake and eat it too! All the goodness from both products but without making a giant mess. In a nutshell, harvest APIs from the API manager to the catalogue.
64 |
65 | 
66 |
67 | ###What technologies is the BCDevExchange custom web application made of?
68 |
69 | The BC Developers’ Exchange is innovative and its audience are innovators. There’s no one product that can address the BC Developers’ Exchange needs and agility is highly valued. A custom web app that leverages many open source components using today’s modern web technologies is a natural choice for the BC Developers’ Exchange. In the BC Developers’ Exchange journey, if we arrive at place that has a known product/service solution, a migration could take place.
70 |
71 | 
72 |
73 |
74 |
--------------------------------------------------------------------------------
/discussion/devregistration.md:
--------------------------------------------------------------------------------
1 |
2 |
3 | ---
4 | [Back to Discussion Index](../discussion_index.md)
5 |
6 | ##Developer Registration
7 |
8 | In this document, we hope to describe the developer registration prototype in the following aspects:
9 | * Purpose;
10 | * Identity framework assessment;
11 | * Source of credentials;
12 | * Architecture;
13 | * Processes;
14 | * Integration technical notes;
15 | * Target state considerations.
16 |
17 | ###Purpose of Developer Registration
18 |
19 | What do developers need to do within BCDevExchange? The following are high-level reasons for developers to register in near term:
20 |
21 | 1. Bi-directional communication
22 | 1. Provide support
23 | 1. Outage information
24 | 2. Registering Applications for API Key Management
25 | 3. Authorizing access to GitHub repositories and/or pull requests
26 | 4. Creating a profile on BCDevExchange to market needs, projects and assets
27 |
28 | Longer term:
29 |
30 | 1. Certify individual and/or organizations
31 | 2. Provide identity and/or certifications claims to participating BCDevExchange members
32 |
33 | ###Prototype
34 |
35 | **Transactional Risk and Level of Assurance Assessment**
36 | The scope of this document and moreover the beginning stages of the prototype is limited to transactions that have a LOW level of risk. Therefore, the solution described here must meet a Level of Assurance Level 1 (LOA1) or greater. LOA1 does NOT require a verified identity record. However, it does require a credential of medium strength or greater, e.g., username and password.
37 |
38 | **Source of Credentials**
39 | Since identity record of the individual is not of significance, we focus on the source of the credentials or even better authentication services. Social logins have medium to strong credentials with self-asserted identity information. GitHub is likely to meet the majority of the demographic BCDevExchange is targeting for the industry developers.
40 |
41 | https://developer.github.com/guides/basics-of-authentication/
42 |
43 | **Architecture**
44 | Logically, BCDevExchange is a separate organization from the B.C. Government. The B.C. Government is a major but not exclusive member of BCDevExchange. A developer may interact with one or more members of BCDevExchange. Provisioning could be automated, for example, registering with BCDevExchange would automatically provision identity to all members. In this scenario, privacy is not respected. We favour user centric internet identity patterns.
45 |
46 | Developers should be able to choose which other members they would like to have relationships with. Participating BCDevExchange members, such as BCDC, will rely on BCDevExchange as authentication gateway and for the BCDevExchange profile. A BCDevExchange profile in the prototyping phase will be simple, “is member”. We envision BCDevExchange profile will provide more substantial claims such as a BCDevExchange Certified Developer. Furthermore, BCDevExchange as an identity provider and authentication gateway, BCDevExchange may be integrated with additional identity providers and authentication services such as BC Services Card. This increases the identity from LOA1 to LOA3 (high assurance identity).
47 |
48 | The following diagram depicts the information flow as a developer signs up to BCDevExchange. For technical readers, these are implemented using OAuth2.
49 |
50 | 
51 |
52 | The following diagram depicts the information flow as a developer signs up to BCDC. BCDC will rely on BCDevExchange as an authentication gateway and simple identity provider. And in turn, BCDevExchange will rely on GitHub for authentication services.
53 |
54 | The API Manager (WS02) cannot readily integrate with social logins. For prototyping purposes ONLY, we will require users create a username and password for the API Manager.
55 |
56 |
57 | 
58 |
59 | Note: users are usually persistently logged onto GitHub so the credentials would not have to be re-entered.
60 |
61 | **BCDevExchange Registration Process**
62 |
63 | The following describe a typical developer registration process within BCDevX:
64 | 1. User navigates to bcdevexchange.org
65 | 2. User clicks Sign Up from any page
66 | 3. User is presented a screen that states a GitHub account is required
67 | 4. User is redirected to GitHub
68 | 5. User either creates a GitHub account or logs in with their existing account
69 | 6. User views GitHub authorization page to allow BCDC access to their identifier, email address, etc
70 | 7. User returns to BCDevExchange logged in
71 | 8. BCDevExchange records a unique identifier, email address, etc
72 | 9. BCDevExchange prompts user to fill or change their pre-populated profile
73 |
74 | **BCDC Registration Process**
75 | As noted above, BCDC will require a registration process in addition to BCDevX. However, the same credentials they used on BCDevExchange would also be available, i.e., GitHub.
76 |
77 | 1. User is logged on to BCDevExchange and navigates to BCDC
78 | 2. User clicks Sign Up from any page
79 | 3. User is presented a screen that states a BCDevExchange account is required
80 | 4. User selects BCDevExchange login
81 | 5. User is redirected to BCDevExchange
82 | 6. BCDevExchange prompts user to sign in or sign up
83 | 7. User selects sign in using GitHub
84 | 8. User views GitHub authorization page to allow BCDC access to their identifier, email address
85 | 9. User returns to BCDC logged in
86 | 10. BCDC records a unique identifier, email address
87 | 11. BCDC prompts user to fill or change their pre-populated profile
88 |
89 | **Integration**
90 | GitHub uses OAuth2 for its authentication service. Because BCDevExchange and the B.C. Government (CKAN and WS02) are separate domains, we expect that two GitHub authorization events will occur.
91 |
92 | https://developer.github.com/v3/oauth/
93 |
94 | **BCDevExchange Integration**
95 | This app is custom built using AngularJS. The backend has not been selected at the time of writing. An OAuth2 library/services must be available for the selected backend platform.
96 |
97 | **BCDC (CKAN) Integration**
98 | CKAN, the underlying software for BCDC, does not have built-in OAuth2 support. However, CKAN organization recognizes the following external for OAuth2:
99 |
100 | https://github.com/conwetlab/ckanext-oauth2
101 |
102 | **API Manager (WS02) Integration**
103 | WS02 does not support OAuth2 out of the box. It does support SAMLv2, but GitHub only provides OAuth2 support. Therefore, for prototype purposes ONLY, the user will be required to create a username and password within WS02.
104 | Target State Considerations
105 |
106 | The above describes the prototype and not the end goal. Here are considerations for target state:
107 |
108 | 1. The B.C. Government’s Enterprise Security Gateway (ESG) integrates with social logins, and BC Services Card.
109 | 2. BCDC uses the ESG to accept IDIR, BCeID, social logins and BC Services Card logins.
110 | 3. BCDC uses SAMLv2 for integration with ESG.
111 | 4. Organization and other affiliation services become available.
112 | 5. A developer certification member management certificate service becomes available.
113 | 6. GitHub APIs are used to grant GitHub roles for certified developers.
114 | 7. API Management integrates with ESG.
115 |
--------------------------------------------------------------------------------
/wireframes/release-1/Lab.bmml:
--------------------------------------------------------------------------------
1 |
2 |
3 | ---
4 | [Back to Discussion Index](../discussion_index.md)
5 |
6 |
7 | #Programs Goal
8 |
9 | The concept of Programs and their accompanying Programs Page is intended to help meet several perceived business needs for Government and BPS –
10 |
11 | - Presenting a description of the Program, and helping to clarify the goals of the Program and related Projects that it encapsulates
12 | - Help illustrate related business processes and business needs, through providing use cases, current and future journey maps, and listing related personas
13 | - Provide some insight into how the program is being delivered, through sharing the perspective of the program owner and its staff, links to question and answer documents, and promoting opportunities for direct engagement
14 | - Expose related Projects and activities that are currently happening or are planned, including backlogs, epics, and user stories
15 | - Provide listings of relevant Projects and Digital Resources (APIs, Data, and Applications), helping to provide context for
16 | - Show Pathway to Adoption options for the Program
17 |
18 | ##Programs In BCDevExchange
19 |
20 | We are introducing the concept of a Program to BCDevExchange, intended to reflect a set of related projects or activities being sponsored or administered by a government or broader public sector organization. Conceptually, a Program exists at a higher level than a Project, and defines the bigger picture goals, objectives, and principles that individual Projects may work towards or support. A Program may also define the framework against which the Projects will be defined and structured.
21 |
22 | The new Program entity will exist above the existing Project entity, with each Program having zero or more Projects related to it. Each Project will reflect different groupings of activities or initiatives being pursued along their own timelines (possibly consecutively or concurrently within a Program). Currently, Resources are generally related to a Project (with the relationship inherited by the Program), but could also be listed directly against the Program.
23 |
24 | #Program Directory
25 |
26 | BCDevExchange will be enhanced to include a Program Directory – a page, accessible from the navigation bar (similar to Resources and Project searches), that provides a listing of all of the Programs registered with BCDevExchange. This directory will display each Program’s title, description, tags, and link to the Programs Page on BCDevExchange.
27 | The contents of the Program Directory will be moderated by the BCDevExchange dev team, through the use of a source file in GitHub (a .yml file in the BCDevExchange-Programs repo). The listing in GitHub will include a URL identifying a separate .md file in the same GitHub repo, which will contain further details for the Program, and used to generate the Program Page.
28 |
29 | #Program Directory
30 |
31 | The Program Directory provides a listing of all of the Programs registered with BCDevExchange. This directory will display each Program’s title, description, tags, and link to the Programs Page on BCDevExchange.
32 | The Program Directory page is moderated by the BCDevExchange dev team, through the use of a programs.yml file in the BCDevExchange-Programs repo. The listing in GitHub will include a URL identifying a separate .md file in the same GitHub repo, which will contain further details for the Program, and used to generate the Program Page.
33 |
34 | To list a Program with the Program Directory function, the following framework / process is proposed.
35 |
36 | ###How to add a new Program to the Program Directory
37 |
38 | 1. Work with the Program Owner to define the Program listing
39 | 2. Access the directory.yml file in GitHub (https://github.com/BCDevExchange/BCDevExchange-Programs/blob/master/directory.yml)
40 | 3. Create space for a new record by copying and pasting an existing record, or copying and pasting the example record structure
41 | 4. Define the title, description, owner, logo, tags, url, and visible for the Program (.yml contains descriptions of what these values to of these)
42 | 5. Commit the changes to directory.yml
43 |
44 | Note: If a logo is referenced in the directory for a Program listing, it will replace the Title display. A Program in the Directory can have a Title or Logo, but not both. Logos can be stored in the Logos Repo in BCDevExchange-Programs.
45 |
46 |
47 | ##Program Page Structure
48 |
49 | The .md file in GitHub will be structured using the following logic, intended to be interpreted by BCDevExchange into HTML. See the exampleprogram.md (https://github.com/BCDevExchange/BCDevExchange-Programs/blob/master/Programs/exampleprogram.md). Not all Markdown features are supported. The focus is on a minimal viable product as the demand for Program Pages is evaluated.
50 |
51 | **Page Title** – Will be automatically generated based on the title in the directory.yml.
52 |
53 | **Section Title** – The title of a section. Used for the page header / titles and section headers. A Section Title should display in its own row. Interpret markdown Header 2 as Section Titles. Any Content that follows the Section title should display as full page width. Section Titles should be left aligned.
54 |
55 |
56 | ##Heading = Example content
69 |bold example content
70 |italicized example content
71 | 72 | **Creating Rows and Sections** – The BCDevExchange Program Page will utilize custom syntax for defining page structure within the markdown document, which can then be interpreted by BCDevExchange when the markdown is rendered into HTML. All of the below syntax can be commented out in GitHub (only making it visible when editing the document / viewing raw markdown), if a more similar look and feel between the GitHub rendered markdown and the Programs Page in BCDevExchange is desired. Syntax can be commented out by adding a start and stop characters around the string being commented out. 73 | 74 | 75 | 76 | [row start] This declares that a row is being created. Page will automatically define the spacing for 2 columns or 3 columns on the page, based on the number of columns that follow. 77 | 78 | [col start] This declares the start of a distinct column. Any Titles or Content that follow will be displayed constrained by the column width. It is recommended that no more than 3 columns be displayed in a single row (this is a style recommendation, not a technical limitation). 79 | 80 | [col end] Declares the end of a distinct column. Subsequent [col start] can be declared. 81 | 82 | [row end] Declares the end of a distinct row. Unless another row is declared, subsequent content will display in full page width. 83 | 84 | **External Resources** - External sites can be linked via standard markdown linking. 85 | 86 | [Link description](www.destinationlink.url) 87 | 88 | **Media** - Images, icons, or other (types to be determined) media can also be displayed on the Program Page, but will need a host location, and linked via standard markdown. Images, icons, and other media can be stored in a repo in GitHub, such as the existing Logos directory. Images should be provided by HTTPS instead of HTTP. 89 | 90 |  91 | 92 | ##How to list your Program 93 | 94 | Programs Markdown template file in BCDevExchange – Programs. 95 | 96 | 1. Program owner forks the BCDevExchange - Programs repo 97 | 2. Program owner copies an existing Programs file or template 98 | 3. Program owner renames the Program file to their Program name 99 | 4. Updates template as per template instructions 100 | 5. Makes pull request back to BCDevExchange 101 | 6. BCDevExchange accepts pull request 102 | 7. Program owner can view their Program through a dynamically generated URL for the Program Page (available before it is visible on the Programs Directory) 103 | 8. Program owner and BCDevExchange confirm the layout of the Program Page 104 | 9. Once approved, BCDevExchange updates directory.yml to make the Program visible (change visible from ‘no’ to ‘yes’) 105 | -------------------------------------------------------------------------------- /discussion/projects.md: -------------------------------------------------------------------------------- 1 |
2 |
3 | ---
4 | [Back to Discussion Index](../discussion_index.md)
5 |
6 |
7 | ##Projects
8 |
9 | **Release 1:** BCDevExchange will support the concept of a Project, which is a record reflecting some sort of initiative, activity, or task that is occurring in the real world, and is presumably of some interest to the members of BCDevExchange. This is intended to allow people to share information of ongoing activities with the rest of BCDevExchange, and could include everything from a concept that people are looking to discuss, to an unmet business need looking for suggestions for a solution, to an active development activity (and using a [Project State](projectstates.md) to help indicate where it currently is). Not all Projects will have any kind of output. While some may produce some sort of usable digital resource, such as an application or piece of code, others may start and end in the Inspiration state, never changing to the Exploration or Delivery states.
10 |
11 | For early releases, we are using GitHub repos to support projects. Issues associated with the Project repo will be used to expose a project backlog, and related opportunities and needs.
12 |
13 | ###Projects and Business Needs
14 |
15 | A number of business needs have been identified that we believe will be met through the use of Projects and Backlogs, with the solutions utilizing either one (either projects or backlogs) or both of these (projects and backlogs). As part of the proposed solutions, the concept of labels and tags will be used, which is the idea of associating one or more tags / labels (pre-defined words or terms), which will assist both the system and its users in easily identifying and associating projects and backlogs with the business need they are helping to meet.
16 |
17 | The following business needs have been identified, and are intended to be addressed by the solutions proposed in this document:
18 |
19 | 1. Pitch an Idea
20 | a. Seeking a Technical Solution
21 | b. Seeking a Business Solution
22 | c. For general feedback from the community
23 | 2. Post an Opportunity
24 | a. With a defined scope (timeline, solution parameters)
25 | b. With an identified exchange of value (credit, recognition, money?)
26 | 3. Search on Opportunities
27 | a. Based on my skills
28 | b. Based on my interests
29 |
30 | ###Need: Pitching an Idea
31 |
32 | Pitching an idea is a pretty wide ranging concept, and could be anything from ‘what about this very specific technical solution to this very specific technical problem’ to ‘what thoughts do people have about a proposed solution to a somewhat vaguely defined but unmet business need’. An idea being pitched may result in one or more projects, or be just a small piece of a single project. Due to the varied nature of ideas, it seems like it would be difficult to nail down a single implementation option under which this business need would be met. Instead, it’s proposed that the framework of GitHub project repos and issues as a whole be used to support the need for pitching an idea.
33 |
34 | In short, the need of ‘Pitching an Idea’ can be met through creating / listing a project (project repo), or through the creation of an issue associated with a project (issue). For discoverability, it is proposed that specific tags be used to identify projects being used to ‘pitch ideas’, and issues use specific labels to identify ‘ideas being pitched’.
35 |
36 | ####Proposed Project Tags (Pitch an Idea)
37 |
38 | Project tags will be identified as part of the project listing in the projects.yml.
39 | Open for Collaboration
40 | Feedback Wanted
41 | Input Wanted
42 |
43 | ####Proposed Issue Labels (Pitch an Idea)
44 |
45 | Issue labels will be assigned via GitHub issues.
46 | Question
47 |
48 | ####Implementation Notes
49 |
50 | To be completed once the above approach is confirmed.
51 |
52 | ###Need: Post an Opportunity
53 |
54 | The business need of Posting an Opportunity is intended to provide a way for project owners to indicate that there is the opportunity for an exchange of value in the context of a project. This could be defined at a project level, where the project as a whole is perceived as a possible opportunity for developers or entrepreneurs to perform work or provide a solution, or at the Backlog / Issue level, where there is a more specifically, scoped out opportunity that is perhaps one of many opportunities associated with a project.
55 |
56 | As part of the project or issue, the person proposing the opportunity would be expected to set expectations regarding scope, timeline, solution parameters, or any value being proposed for exchange.
57 |
58 | ####Proposed Project Tags (Post an Opportunity)
59 |
60 | Project tags will be identified as part of the project listing in the projects.yml.
61 | Opportunity
62 | Value Exchange
63 |
64 | ####Proposed Issue Labels (Post an Opportunity)
65 |
66 | Issue labels will be assigned via GitHub issues.
67 | Help Wanted
68 | Enhancement
69 |
70 | ####Implementation Notes
71 |
72 | To be completed once the above approach is confirmed.
73 |
74 | ###Need: Search on Opportunities
75 |
76 | The business need of Searching on Opportunities is intended to provide a way for people (probably developers and entrepreneurs) to find opportunities which could result in an exchange of value, and specific to their skills and interests. This business need is intended to be met through enhancements to the BCDevExchange Project Search functionality.
77 | The Search on Opportunities business need solution will leverage the same labels and tags proposed for the Post an Opportunity business need, as the Search need is performed against the data provided generated from Post need.
78 |
79 | ####Implementation Notes
80 |
81 | 1. Create new logic to display the languages associated with a project, based on the GitHub repo the project is located (specific implementation to be determined)
82 | 2. Create new logic to display tags associated with each project returned by the Project Search. These will come from the new projects.yml file in GitHub (considered the source of truth), and fully moderated by the BCDevExchange team, so defining filters / permitted tags is unnessecary
83 | 3. Create new logic to display specific Issue Labels for issues in a project’s backlog returned in the BCDevExchange Project Search (the specific labels should be driven by the labels defined in the context of the Pitching an Idea and Post an Opportunity business needs above).
84 | 4. As the query against GitHub Projects will be an explicit call to the projects.yml file in the BCDevExchange-Projects repo, there is no need to filter based on README.md tags or association with BCDevExchange accounts. The projects.yml file will be considered the source of truth for the following information displayed in the Project Search results on BCDevExchange: Title, Description, linked URL, Tags, and Source. However, the Backlog link, Issues count, Issue labels, and Languages information will not be stored in resources.yml, and will be pulled from the actual referenced repos themselves.
85 | 5. Issue labels are configurable by repo, and can be user created and defined. In able to maintain moderation of the content on the Project Search page, we will need to explicitly define exactly which issue labels we will display on BCDevExchange Project Search results.
86 | 6. GitHub has several default Issue labels. It is suggested that we leverage these existing labels, specifically ‘Help Wanted’, ‘Enhancement’, and ‘Question’. Leveraging existing labels is thought to be in line with several of the dev principles, but could be expanded to include BCDevExchange specific issue labels in the future if necessary.
87 |
88 | ####Summary: Tagging guide
89 |
90 | Provide a summary of project tags and issue labels used to meet the business needs listed above. To be completed once the above approach is confirmed.
91 |
92 | ##Notes
93 | **Future State:** Like resources, projects are created in the context of a specific [profile](profiles.md) (either against an Individual profile or Organization profile). Unlike Resources, but like [Organizations](organizations.md), projects can be owned and shared by multiple users (against a specific profile), with certain profiles having different rights to maintain the project. Like organizations, users can be invited to a project (at the profile level), or can request an invite to the project (at the profile level). Users who are not part of a project can still sign up to follow a project, to receive notifications of updates.
94 |
95 | Within the context of a project, users can create posts to share with BCDevExchange community as a whole, or only to users associated with the project, and respond to those posts. Projects may also link to related sites, such as GitHub repos or forums outside of BCDevExchange.
96 |
97 | Projects may be related to one or more BCDevExchange resources, with the same Resource possibly being associated with multiple Projects, and identified via the same pool of metadata tags that are used to define resources. BCDevExchange would facilitate searching on projects similar to resources. Projects can also be related to other Projects, and to one or more Organizations.
98 |
99 | ###Mockup
100 | 
101 |
--------------------------------------------------------------------------------
/wireframes/release-2/Environmental Reporting.bmml:
--------------------------------------------------------------------------------
1 |