|
THE FOLLOWING DESCRIBES THE TERMS ON WHICH REMOTEHIREMAN DEALS WITH YOUR DISPUTES.
- Language
- Acceptance Of Deliverables
- Rules Of Arbitration
- Language
-
You agree to use English, French, Spanish or Chinese in all communications on the site to
allow RHM to properly arbitrate in the case of a dispute. Should the user violate this and RHM
determines it cannot deliver a fair arbitration, the user will forfeit arbitration.
- Acceptance Of Deliverables
-
After coding is completed, the deliverables will be sent from the Seller to a location
on the site where the Purchaser may download them.
If the deliverables are 100% satisfactory to the purchaser, then Purchaser agrees
to indicate 100% acceptance of the deliverables via the web site (or a partial
acceptance if the deliverables are only partially complete and satisfactory based
on pre-agreed upon milestones) via the arbitration procedure.
Purchaser assumes sole and complete responsibility for adequate testing
to determine for themselves whether or not the deliverables are 100% satisfactory
or not (or partially satisfactory if pre-agreed upon partial milestones have been
created). Purchaser agrees to never accept any work before deliverables have been
100% tested and they are 100% satisfied. If against the wishes of RHM, Purchaser
accepts work without the above two items being true, Purchaser agrees
that the acceptance and payment fall under the risky category of "advance payments"
as detailed elsewhere in this contract, and can result in a loss of funds for
the Purchaser. RHM cannot discourage this sort of high risk activity enough.
Realizing that the Seller will not be credited until work is fully or partially accepted,
the Purchaser agrees to do all testing in as timely a basis as possible. Purchaser
also agrees not to withhold acceptance unreasonably.
Should the Purchaser not be 100% satisfied, then Purchaser agrees to not accept
the work and instead notify the Seller as well as RHM of the problem in a timely
basis so that it can be resolved. Should there be any dispute by either Purchaser
and Seller regarding acceptance, both Seller and Purchaser agree to abide by the
RHM rules of arbitration in later section.
- Rules Of Arbitration
-
These rules of arbitration exist to ensure a fair and safe environment for the buying and
selling of computer software and related systems. Should a dispute arise over the completion
of a project, the allocation of escrowed funds, or any other issue, both Purchaser,
Seller and RHM agree to the following rules:
- About Mediation / Arbitration
Should the Purchaser and Seller not be able to come to agreement on acceptance,
(including but not limited to whether deliverables have been met and bid acceptance
should occur), both parties agree to designate RHM as sole mediator and arbitrator
(two distinct roles). RHM agrees to mediate and arbitrate fairly and impartially
according to the rules in this section, as they apply. Purchaser and Seller agree
that RHM's decision is final and binding to them and hereby waive any other further
legal challenges or remedies including but not limited to civil or criminal
litigation against the other party or RHM.
- Mediation
Before arbitrating (however after efforts have been done and both parties can definitively
not come out to a solution ie: the site provide an arbitration message board which
allow both party to discuss their argument and may come to an acceptable
compromise so RHM do not have to interfer), RHM may attempt to first mediate
a mutually acceptable compromise solution between both parties if it
determines the option is a viable one. A mediated compromise can provide
a quick and easy way for both parties to obtain a successful outcome,
without the time and energy required by a full-blown arbitration.
Both Purchaser and Seller understand and acknowledge that they are NOT
required to accept any mediation proposals. RHM acknowledges that the
refusal of any party to accept a mediation proposal will not affect its
standing in the subsequent arbitration.
If a mediation succesfully occurs in which the original contract is either
reduced or cancelled, RHM will document what occured by placing a rating on
one or both parties' records, as detailed below under "RHM Ratings".
Should either party not agree to a mediation compromise, or should RHM
(at it's sole discretion) determine that the option is not a viable one,
the process moves on to arbitration (Still the same Message Board).
- Arbitration
Arbitration of the bid request is based solely on whether or not the Seller met the conditions
specified in the Purchaser's 'Entire Request' (unless either Purchaser or Seller prematurely
forfeits by the other rules of arbitration detailed below).
The 'Entire Bid Request' is defined as:
1. The original bid request posting on the site (which includes but is not limited to the description,
attachment and deliverables)
2 The subsequent clarifications and/or changes made in bids/comments from both sides in
the site bidding/comment system.
Both Purchaser and Seller agree that any discussions conducted outside of the site (including email,
off-site chat and oral conversations over the phone) are NOT considered part of the 'Entire Request'
and WILL NOT be taken into account.
RHM has found that due to poor wording or lack of attention to detail, that sometimes portions
of the 'Entire Request' contradict other portions or are unclear. In the event that either
Purchaser or Seller disputes with the other party any portion of the 'Entire Request'
(including but not limited to disputes over an alleged contradiction, interpretation, or
applicability) RHM will be the final determiner of the best method of resolving the issue.
It will make this determination using the most impartial method that it can, in good faith, formulate.
Despite repeated warnings to both Purchaser and Seller to the contrary, occasionally RHM
finds that both parties have neglected to use the site to detail key items of the 'Entire Request',
withholding the information necessary to make what RHM feels is a "just" arbitration decision.
This can happen due to a deliberate manipulation by one party and/or due to genuine ignorance
of the consequences of such behavior by one or both parties. Should RHM determine this to be
the case, it may extend the definition of the 'Entire Request' to include items not normally covered (such as 3rd party chat logs). However, neither Purchaser nor Seller may demand such an extension nor possess the "right" to such an extension. Instead Purchasers and Sellers agree to properly document the 'Entire Request' on the site as RHM warns,
and not expect, or count on an extension to occur in any arbitration. Site users who
repeatedly do not use the site to document the 'Entire Request' may be ejected from
the site.
- Quick Resolution Arbitrations
If a Seller does not upload completed deliverables to the site by the delivery deadline
posted by the Purchaser, then the Seller will be found in forfeit of the arbitration.
However, to prevent an unscrupulous Purchaser from unfairly manipulating a Coder to
obtain free work; should RHM discover evidence that it feels indicates that the
Purchaser continued to work with the Seller after the deadline, then the deadline
may be deemed "Implicitly Extended" by the Purchaser's actions nullifying the
previous deadline and the above mentioned forfeiture.
If the timezone for a deadline is ambiguous, then Purchaser and Seller authorize RHM
to determine the time zone to be enforced, using whatever method it deems (in it's sole opinion)
to be appropriate.
If the Seller has already agreed to provide status reports prior to the arbitration and
did not fulfill that agreement, then they also be found in forfeit of the arbitration.
However, to prevent an unscrupulous Purchaser from unfarily manipulating a Coder to
obtain free work, should RHM discover evidence that it feels indicates that the Purchaser
continued to work with the Seller after the status report requirement was not met,
then the Purchaser will be considered to have waived their rights to cancel on
that particular missed stats report nullifying the previous deadline and the
above mentioned forfeiture. Note: status reports are NEVER required of the Seller
while arbitration is in process.
- Insufficient Progress Arbitration
If the Purchaser charges that the Seller is not making sufficient progress on a request,
the Seller must supply specific demonstrable proof to the contrary.
Examples of demonstrable proofs of progress are (depending on the level of progress expected)
programming requirements, designs, prototype, code and/or test cases. If RHM determines that
demonstratable proof of progress has not been supplied, the Seller will be found in
forfeiture of arbitration.
- Deliverable Dispute Arbitration
The typical arbitration case involves a disagreement on what was delivered. The Purchaser
typically claims that they did not receive 100% of the 'Entire Bid Request' and the Seller
typically claims that they did provide this to the Purchaser.
The only way to determine who is being truthful and who isn't, is to test the deliverables.
When this occurs, an RHM tester will perform a "flaw list verification" where they compare
the Purchaser's list of problems (the "flaw list") to the actual application/deliverables.
Should one or more flaw list items be verified, then the Purchaser wins arbitration.
Should no items be verified then the coder wins arbitration. The process works as follows.
- The Flaw List
First RHM will request a detailed flaw list from the Purchaser detailing exactly what the Purchaser
contends was not delivered, and (if appropriate) instructions on how to duplicate the alleged behavior.
Purchaser agrees to provide the above when requested by RHM, so that RHM can confirm
or deny whether the original bid request requirements were met or not. Should the
Purchaser not provide the flaw list then they will be found in default of arbitration.
Note that all flaw list items will be screened per the "Flaw List Exceptions" rule below.
An unscrupulous Purchaser who knows that they will lose arbitration, might be tempted
to unfairly delay the inevitable payment to the Seller, by delivering flaw lists in
'piece-meal' fashion. To prevent this, the Purchaser agrees that any flaw list they
present is the full, complete and final flaw list.
Occasionally, the arbitrator may add items to the initial flaw list that they feel are
pertinent, and these may even be items suggested by one of the involved parties. However,
both Purchaser and Seller agree that only the arbitrator may do this, and that no other
party may.
- Testing Venue
Since the deliverables must function in the Purchaser's environment
for acceptance, and the Purchaser is the party creating the "flaw list", the Purchaser
will be responsible for hosting the testing venue. However, if the coder is determined
to have not released the deliverables in question to the Purchaser, the Coder will be
responsible for hosting the testing venue. RHM does reserves the right to move responsibility
for the testing venue to another party if it (in it's sole opinion) believes a fairer result may
be achieved. Additionally, RHM may choose to host the testing venue itself,
if it (in it's sole opinion) determines:
a). that the arbitration venue responsibility would not be better served by either the Purchaser or the Seller
b). that significant setup assistance will not be required from the Seller (since a Seller can take
advantage of such a situation to do configuration tweaks that were not done on the Purchaser's system)
c). that it has an existing environment adequate to testing the deliverables
Both Purchaser and Seller agree that if required to provide the testing venue, they will
provide RHM with access to all aspects of their environment that are necessary for RHM to:
a). Verify or deny the Purchaser's claims in the flaw list
b). Verify or deny that deliverables have been modified to cheat the testing process
Note that these aspects may include (but are not limited to) software, hardware, documentation,
remote access to systems etc. Should the party responsible for hosting the testing
venue refuse to provide all aspects of the testing venue when required to, they will
default on the arbitration and forfeit it.
RHM may use file comparisons (and/or other means) to ensure that modification
of deliverables does not occur by the testing venue host. If RHM (in it's sole
judgment) determines that the host has modified deliverables to influence an
arbitration unfairly in their favor, the host will forfeit arbitration, be found
in default of their contract under the terms of 'fraud', and will have their
account involuntarily closed.
- Flaw List Exceptions
Certain types of flaw list items will not be tested and must be removed from the
flaw list. They include:
a). Subjective Items:
Items that cannot be objectively stated cannot be objectively tested.
The Purchaser will be given the chance to restate them objectively, but
if they do not, then they will be removed from the flaw list.
b). Cosmetic Items:
The Seller acknowledges and understands that they are expected to follow software development
standards, which dictate doing adequate testing to ensure that the application received by
the Purchaser contains all agreed upon functionality and in stable working condition. However,
the Purchaser also acknowledges and understands that the complexity of modern software makes
it impossible to create software that is 100% bug free (Windows is an excellent example).
To ensure a fair test, certain items called "Cosmetic Items" will be removed from the flaws list.
"Cosmetic items" are defined as flaw list items that are infrequent, do not affect the major
functionality of the deliverables and can be corrected very easily. Some examples are a
web page with the wrong background color or "typos" in a few data entry fields. Should
items be found to be "cosmetic items" and the Seller actually wins arbitration, then they
will be required to fully correct them before receiving payment.
Note that should the tester determine that the frequency of potentially cosmetic items
shows a lack of adequate testing by the Seller, then the 'cosmetic' items will NOT be
removed from the flaw list.
c). Setup program bug items:
The flaw list may contain reference to items caused by a faulty setup program.
Due to the exponential number of different computer configurations in the world,
setup programs sometimes do not run perfectly on every machine. More importantly,
sometimes these issues cannot be identified until they are run on a particular
"problem configuration" machine. If the tester determines that one or more setup
program related flaw items fall in this category and could not have been prevented
by the Seller using adequate testing using their own equipment and proper testing
measures commensurate with the bid request, then these flaw items will not be considered.
- Forfeiting Arbitration by not responding
Purchaser agrees to be prompt in corresponding with Seller and RHM, including final acceptance
of 'Work Complete'. Should a Purchaser not respond to RHM arbitration communication in 3
days, they will forfeit arbitration at RHM's discretion. Should a Purchaser not fully
comply with RHM requests to either certify Work Complete or produce a flaw list within
5 business days, then will forfeit the arbitration at RHM's discretion. If RHM determines
a forfeit has occurred then the escrowed funds will be awarded to the Seller.
Seller agrees to be prompt in responses to Purchaser and to RHM. Should a Seller
not complete status reports prior to the beginning of the current arbitration or
respond to RHM arbitration communication within a timely basis of 3 business days,
they will forfeit arbitration at RHM's discretion. If RHM determines a forfeit
has occured, then in addition to the Seller's bid being cancelled, all of the
Seller's other bids which have been selected by Purchasers may be assigned to
another (presumably more responsible) Seller. This may be done with or without
notice to the original Seller.
- When the Purchaser Wins Arbitration
If the Purchaser wins arbitration, they may, at their option, apply the entire
escrowed amount to a new Seller at no charge. RHMwill offer the Purchaser options
(if available) of switching to other Sellers on the original bid, opening a new
bid request to get new Seller bids, or otherwise offering to connect the Purchaser
with Sellers for the purpose of completing the project.
The Purchaser also has the option to cancel the bid request and request a
refund of escrow funds. To compensate RHMfor the costs in this process,
all refunds of this nature are subject to a 3.5% cancellation charge for
the Purchaser. However, to compensate the Purchaser when cancellation is
not their fault...should the Seller be determined by RHM to be "at fault"
for the cancellation, then funds in the Seller's account (if available) will
be used by RHM to lessen or completely eliminate this charge.
If the Purchaser is awarded back 100% of their escrowed funds on a project, then
they agree that the deliverables created by the coder may NOT be kept by the Purchaser.
Purchaser agrees to relinquish possession by promptly and completely destroying all
deliverables and copies of deliverables in their possession.
- One Party Rating the Other Party
To prevent 'retaliatory ratings', RHM reserves the right to suspend rating rights on either party
and/or to remove/edit ratings that it judges to be either retalitory in nature or involving
a "trade" of favorable ratings to avoid a deserved bad rating.
|