- Case Number: a20091118.3
- Status: closed
- Claimants: Dirk Astrath
- Respondents: CAcert Inc.
- Case Manager: Martin Gummi
- Arbitrator: Mario Lipinski
- Former Arbitrator: Philipp Dunkel
- Date of arbitration start: 2010-09-08
- Date of ruling: 2010-11-03
- Case closed: 2010-11-25
- Complaint: problems with check-boxes on website forms
(i would NOT publish this in detail on the wiki until the bug is fixed ... but it's not my decision ... ;-) ) after some assurances where done on openrheinruhr last weekend, i watched alexander b. and joost s. entering the caps into the system. ...
- Relief: Correct the problems with check-boxes on website forms
Before: Arbitrator name arbitor (A), Respondent: Philipp Guehring (R), Claimant: Dirk Astrath (C), Case: a20091118.3
further details not added here, since an arbitrator descides how to handle this
History Log
- 2010-02-05 A: Changed Respondent, since the initial entry was incorrect.
- 2010-02-05 A: CM please send initial email to claimant
- 2010-02-15 C: Accepts CCA/DRP
- 2010-09-08 A: sent out letter to involved and related parties
- 2010-11-03 A: ruling
- 2010-11-25 A: Bug reported as #894. closed.
Ruling
As Martin already wrote in his initial mailing we will be required to work together after this arbitration, so we should maintain a positive and helpful spirit at all times. This especially applies to this case.
I do not see a violation against Assurance Policy. The data submitted to the system has to be checked by the assurer, not the system. It is the assurers obligation to make sure, his assurance conforms to the assurance policy.
Then there is a claim that Philipp Gühring violated SP. The violation is dated April 2009. How fix is the date mentioned here? How do we know that the violation took place exactly then. Or could the change have been made earlier and it is just the date the source code was checked in? Nevertheless, SP went into draft and so became binding one week before the mentioned date. Looking at the Software Assessment Project today, there are no working procedures in place to apply software changes one and a half year after that. So this violation might be seen in a grace period before the necessary procedures could be established or the new requirements realised. However, as already done so in a20090810.1 (https://wiki.cacert.org/Arbitrations/a20090810.1) which was after the claimed SP violation happened, Philipp should feel reminded again to follow SP regarding software changes.
Then, there is a bug in the CAcert software. However, it is not the intention of arbitration to have bugs in the CAcert software fixed. Searching bugs.cacert.org did not show any records, regarding this. This might be a private bug which cannot accessed by A or not entered. If not entered, C is now obliged to report the bug using the bug tracking system, not arbitration. Since the bug is misleading for our users and anti-supporting our policies, being an active member of the software team, C is further obliged to get this bug fixed and get the fix applied to the production system with high priority, following the regular update requirements as of SP.
Execution
C to document bug at bugs.cacert.org and report back to arbitrator with bug number for documentation. C should fix bug later.