You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 4, 2018. It is now read-only.
Businesses should be able to submit a proposal for a project to be worked on by our members.
Definitions
client - an Operation Code member that needs work to be done proposal - a unit of work to be done admin - an Operation Code member that will be maintaining the jobs portal member - an Operation Code member interested in working on a proposal
Scenarios
As a client
When I visit jobs.operationcode.org
I should see an overview of how the process works.
I should see that when I post a job it will be worked on by members of Operation Code.
I should see how many members we have enrolled in the jobs program
I should be able to create a proposal
When I visit jobs.operationcode.org/proposals
I should be able to create a proposal
I should be able to specify the following attributes:
I should be able to view all of my existing proposals
I should be able to view the status of a proposal
I should be able to update the status of a proposal
As an admin
When I visit jobs.operationcode.org/proposals
I should be able to view a list of all proposals
I should be able to update the status of a proposal
I should be able to view all members enrolled in the jobs program
I should be able to filter users based on their skills
I should be able to see member applications to a proposal
I should be able to approve or deny member applications to a proposal
As a member
When I visit jobs.operationcode.org/proposals
I should be able to view a list of all active proposals
I should be able to filter proposals based on skills needed
I should be able to apply for a proposal
Proposals
In order to maintain quality each new proposal should move through several states.
When a proposal first comes in it should be in the New state. An email should be sent to admins for each new proposal.
The next state will be In review. Admins will be reviewing the proposal to make sure it's valid and for more complex proposals possibly contact the client to identify milestones and timelines.
After the proposal is valid it will be moved to the Client Review state. In this state contacts will be drawn up and the client can verify the final proposal.
From 'Client Review' the client can chose to go to either the 'Ready' state or the 'Published' state. The only difference between the two states is Ready won't show up in the user proposal list, where Published will. A user should be able to transition from Ready to Published at any time.
During the Published state members will be able to apply to the proposal. Admins should contact each applicant to make sure they're capable of the required tasks and to determine what resources they might need.
From the Published state a client should be able to move to the Canceled state. This will close the proposal and no more actions can be taken.
From the Published state an admin should be able to move to the Accepted state. This means members have applied and been approved to work on the project and work can begin.
From the Accepted state an admin should be able to move to the In Progress state. This means members have begun work.
From the Accepted state an admin should be able to move to the Client Acceptance state. At this point work will be demonstrated to the client.
From Client Acceptance a client should be able to move to the Client Accepted state. This means the work demonstrated is valid and the project is complete. Any code or artifacts should be delivered.
From Client Acceptance a client should be able to move to the Changes Requested state. This means changes are needed to meet the client's needs. Admins should be notified to make sure the changes still fit the scope of the proposal.
From Changes Requested the client should be able to move to the Client Accepted state.
From Client Accepted an admin should be able to move to the Billing state.
From the Billing state an admin should be able to move to the Completed state.
MVP Criteria
Dockerized
k8s config
Backup plan
Integrates with existing oc.org SSO
Emulates fit and finish of operationcode.org
Proposal CRUD
Members can apply to proposals
Tests
The text was updated successfully, but these errors were encountered:
On Aug 4, 2017, at 1:04 AM, Seth Bergman ***@***.***> wrote:
It's been pushed to the requested repo, https://github.com/OperationCode/jobs.git and can be viewed here:
Demo: => Jobs Portal <=
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
rickr
changed the title
Build contracting portal.
Build contracting portal
Aug 4, 2017
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Businesses should be able to submit a proposal for a project to be worked on by our members.
Definitions
client
- an Operation Code member that needs work to be doneproposal
- a unit of work to be doneadmin
- an Operation Code member that will be maintaining the jobs portalmember
- an Operation Code member interested in working on a proposalScenarios
As a client
As an admin
As a member
Proposals
In order to maintain quality each new proposal should move through several states.
When a proposal first comes in it should be in the
New
state. An email should be sent to admins for each new proposal.The next state will be
In review
. Admins will be reviewing the proposal to make sure it's valid and for more complex proposals possibly contact the client to identify milestones and timelines.After the proposal is valid it will be moved to the
Client Review
state. In this state contacts will be drawn up and the client can verify the final proposal.From 'Client Review' the client can chose to go to either the 'Ready' state or the 'Published' state. The only difference between the two states is
Ready
won't show up in the user proposal list, wherePublished
will. A user should be able to transition fromReady
toPublished
at any time.During the
Published
state members will be able to apply to the proposal. Admins should contact each applicant to make sure they're capable of the required tasks and to determine what resources they might need.From the
Published
state a client should be able to move to theCanceled
state. This will close the proposal and no more actions can be taken.From the
Published
state an admin should be able to move to theAccepted
state. This means members have applied and been approved to work on the project and work can begin.From the
Accepted
state an admin should be able to move to theIn Progress
state. This means members have begun work.From the
Accepted
state an admin should be able to move to theClient Acceptance
state. At this point work will be demonstrated to the client.From
Client Acceptance
a client should be able to move to theClient Accepted
state. This means the work demonstrated is valid and the project is complete. Any code or artifacts should be delivered.From
Client Acceptance
a client should be able to move to theChanges Requested
state. This means changes are needed to meet the client's needs. Admins should be notified to make sure the changes still fit the scope of the proposal.From
Changes Requested
the client should be able to move to theClient Accepted
state.From
Client Accepted
an admin should be able to move to theBilling
state.From the
Billing
state an admin should be able to move to theCompleted
state.MVP Criteria
The text was updated successfully, but these errors were encountered: