General FAQs

What is Worklist?

Worklist is High Fidelity's job tracker and marketplace for software development. We use it to supplement our internal team.

I'm a web programmer, will I be able to find work here?

We have both PHP/MySQL (Worklist) and Ruby/Postgres/Redis (High Fidelity) projects. We are often looking for good front-end web developers with a keen eye for detail. More web-based projects will be coming as High Fidelity grows. We also have a growing need for JavaScript developers who are open to learning Hifi JavaScript.

I'm a C++ programmer, will I be able to find work here?

Absolutely. High Fidelity is cross-platform and contains myriad components, most written in C++ with heavy utilization of Qt. In particular, we have a growing need for developers on Windows.

Why do I need a GitHub account?

Worklist is completely federated with GitHub. We require write access on repositories in order to create branches and pull requests from Worklist; for example, when you receive a bid acceptance on a Job, a branch is created on your GitHub account under the Job's ticket number. Later in the process, when you change the status of a Job on Worklist to "Code Review," a pull request is automatically created from the Job's branch. Even private repo access is necessary as some of the code in the High Fidelity architecture is not public.

What is a Job?

A Job can be a feature, a bug, or any development (or otherwise) related task. Most Jobs will be software development related, but some could be about sound design or content development or younameit — Worklist is intended to be malleable, adapting as High Fidelity's needs change.

What is the difference between a Developer and a Designer?

Developer refers to the person performing the actual work on a Job. The Designer is the Job Manager.

What is a Bid?

A bid is a Developer's proposal to perform work on an Job. Bids consist of 1) the amount you would like to be paid, 2) the approach you will take to complete the work needed to resolve the Job, 3) the amount of time that it will take to complete the work, and 4) how long you want the bid to remain active — the maximum time and our default is 7 days.

When you enter a bid, it is always better to give a brief, yet detailed, description of how you intend to address the Job requirements. Designers are not just looking for the lowest bid; we are looking for a considered bid that has some thought behind it while not being unrealistic in cost.

What is a Fee?

In addition to the initial bid, you will probably also see one or more fees attached to a Job. During the course of a Job, fees are added for code reviews (automatically calculated for most projects), testing or other help. We encourage Developers to use their best judgment when fee'ing in.

Developer FAQs

What's the best way to get started?

Browse our Jobs page to view the type of work we're doing and join us in our Gitter chat room where there are almost always other people around to answer questions and help you get started.

What about Coding Standards?

All merged code will be reviewed to make sure it follows our coding standards.

How can I locate Jobs to Bid?

Go to our Jobs page and select "Bidding" from the status drop down. This will show you a list of all currently open Jobs.

What is the workflow of an Job?

Jobs on Worklist go through various statuses from preparation through release. Once your bid is accepted, you might find this cheat sheet helpful until you get the knack of our workflow.

Stage One: Preparation > Job Setup
  • Suggestion - Worklist allows anyone to make suggestions for improvements to any active project. When Suggestion Jobs are added, Designers are notified via email and they decide whether or not to move them into Bidding.
    Sometimes when a Developer has a suggestion, they will also have a particular solution in mind and be willing to do the work. Once a Developer adds a Suggestion Job, they have the ability to add a bid which in turn changes the status to Bidding. Designers are again notified and make the final decision on whether or not to go ahead with the Job.
  • Pass - If for some reason a Designer decides not to move an Job into Bidding, they will set the Job to Pass. Jobs in Suggestion are also auto-passed once they age 30 days.
  • Bidding - Once a Job is set to Bidding by a Designer, any Developer can put in their offer. Designers will review bids and accept based upon the best match to the Job requirements.
Stage Two: In Progress > Getting Jobs Done
  • In Progress - Once a bid has been accepted, the Job will automatically set to In Progress status. It will remain there until the Developer is done with the work.
  • QA Ready - When the Developer is ready for their work to be functionally tested, they will commit the changes to their branch (no Pull Request at this point) and set the Job to QA Ready. At this step in the process, the Designer will test the functionality in the Developer's sandbox and then either ask for modifications or indicate their approval to move to Code Review. Setting the Job to Code Review will automatically generate a Pull Request(PR) in GitHub.
  • Code Review - Code Review means the new code is ready to be reviewed by another Developer. If the reviewer finds any problems, they are either worked out in real-time in our Gitter or via comments added to the Job ticket. Once all requirements have been fulfilled, the Developer commits the code, verifies that the changes have been merged into the live repository and sets then sets the Job to Merged.
Stage Three: Finished > Your Job is Done
  • Merged - Once your Job is merged into the GitHub Master Repository, the Developer sets the Job to Merged. The Job Designer will again be notified via email. This stage allows Designers additional time once the Job is live to verify the new functionality in production. If all is good, they will move the Job to the final status: Done!
  • Done - The Developer will not be paid until the Job is moved into Done status. Done Jobs will be picked up in our payment system during the next payment run via Paypal, currently twice a week.

What is a reasonable bid amount?

A bid is simply defined as the amount of money you will ask for completing the task described by a Job write up. You can browse through Done Jobs to get a good idea of what others have charged for similar Jobs. When considering a Job, be sure to carefully think about any problem areas or potential extra work before placing your bid, as your bid is considered an agreement between you and Worklist for any given Job.

Can I view the source code and/or download it to my own server?

Yes! Our two main repositories, High Fidelity and Worklist are housed on GitHub. The repositories are public and you can browse the code there. You can read more on the GitHub process in our Worklist wiki.

I tried to bid on a Job and it said I am not eligible to bid, what's wrong?

Before you can place a bid, you need to set up your payment information in your profile settings. You need to both add your Paypal address and, if you're in the US, you will need to upload your W9 for our verification.

After I have completed my work, how do I get paid?

Once you've finished work and it has had a functional and code review completed, you should set the Job to Merged. The project Designer will then need to verify it works in production and will then set the Job to Done. You will not get paid until this happens. Please view the Project Status flow for more information. All payments are currently handled through Paypal. When you create your worklist account, you'll be asked to supply your Paypal email address. We will pay as quickly as possible after a Job is marked Done in the worklist (this is done by the person who created or is the Designer for the Job).

Who is eligible to perform code reviews? How do I become eligible?

The right to code review is a special privilage granted by project admins. Ask @kordero, @joanneci or @problem if you think you're ready to watch over our Worklist code. Ask @birarda or @problem if you feel your ready to review High Fidelity code.

If you meet the Code Review qualifications (essentially, we just want to be able to trust you), you will be able to start a code review by clicking the Start Code Review button within a task. If not, a hover message will appear over the button stating that "You are not Authorized to Code Review this Job".

Where can I go for more information?

We have a number of GitHub Wiki's containing a wealth of information:

Or just chat with us in Gitter.