H-FOSS Code of Conduct Draft

3 views
Skip to first unread message

Chamindra de Silva

unread,
Oct 4, 2010, 3:17:47 PM10/4/10
to Mark Prutsalis, humanita...@yahoogroups.com, humanita...@googlegroups.com

On Mon, Oct 4, 2010 at 11:57 PM, Mark Prutsalis <ma...@sahanafoundation.org> wrote:
However, as some know (and for those who don't, let this serve as an invitation to join), we have started a new humanitarian-foss discussion list to help coordinate the efforts of the many humanitarian free and open source software projects involved in disaster and crisis response, as well as several stakeholders (you'll find us on google groups - humanita...@googlegroups.com) - such as Sahana, Usahidi, InSTEDD, Open Street Maps, and others.  Add this to the mix and perhaps we can transition this list to an archive as suggested.

On a separate note as Mark brought up the Humanitarian-FOSS group, would like to share a code of conduct that we tentatively agreed between the H-FOSS projects:
 

--- Copied below -----

Given that the solutions we deploy helps to save lives and alleviate suffering it is important to be cognizant of the impact of your decisions and conduct

  1. Keep tools simple, usability the focus and end users and alleviation of suffering for victims the goal
  2. Strive to collaborate and integrate with our H-FOSS and other aligned solution providers to provide a holistic solution even if it means there is some mutual redundancy (which is positive)
  3. Support Open Standards and look to implement and test them with others in advance in your H-FOSS product
  4. Adhere to globally and local rules of respect and etiquette in your interactions with other developers, users, responders, etc. Strive to understand their point of view that may bias their preferences.
  5. Understands the client. Let the system adopt to their ways of doing things and not the other way around.
  6. Implementation biases and commercial interests should be avoided as much as possible in the solutions you recommend
  7. Actively share your knowledge and best practices with other projects and encourage reuse
  8. Try your best to help but work towards not becoming a bottleneck or single point of failure during a disaster response effort. You can do this by keeping your solutions simple (KISS), providing clear developer documentation.
  9. If you are volunteering to respond, make a commitment and make sure you understand what is expected of you and that you can commit that time for the expected duration
  10. If you know your tool has major points of failure, do not gloss over them but ensure you set that expectation with users during a response effort. It might still be the best option.
  11. Support and promote local capacity and diversity in your community and support infrastructure. Any form of harassment is completely unacceptable

    We are also working on a simple maturity model, more as a guideline of where we want to get to as individual projects and ways we can improve, which was based on a discussion we had at Camp Roberts on some of the gaps we see that need to be addressed in projects.


    Your comments, contributions and improvements are most welcome,

Chamindra de Silva
http://chamindra-de-silva.blogspot.com | http://twitter.com/ChamindraS 

Chamindra de Silva

unread,
Oct 11, 2010, 3:13:54 PM10/11/10
to humanita...@yahoogroups.com, Mark Prutsalis, humanita...@googlegroups.com
Tim,

Sorry for the late reply, but I am not sure if I totally agree with that. certainly point 1 is what it is all about, but not all have the same definition of what that implies. The remaining points make it explicit based on a lot of things that have cropped up in environments where people should anyway be well aware of point 1. Avoiding ambiguity and having such clear values also makes it easier and more efficient to work in harmony in disaster response.
On Tue, Oct 5, 2010 at 2:13 AM, Tim McNamara <pape...@timmcnamara.co.nz> wrote:
 

Hi Chamindra

These principles are quite verbose, with some elements of each principle verging on tautology. Some principles unnecessarily duplicate each other. In effect, by adding length and complexity to the principles, we are undermining the first one.

In general, I would change the language to "we will", "we support'. This will emphasise the community aspect.

On 5 October 2010 08:17, Chamindra de Silva <cham...@opensource.lk> wrote:
Given that the solutions we deploy helps to save lives and alleviate suffering it is important to be cognizant of the impact of your decisions and conduct
  1. Keep tools simple, usability the focus and end users and alleviation of suffering for victims the goal
  2. Strive to collaborate and integrate with our H-FOSS and other aligned solution providers to provide a holistic solution even if it means there is some mutual redundancy (which is positive)
  3. Support Open Standards and look to implement and test them with others in advance in your H-FOSS product
  4. Adhere to globally and local rules of respect and etiquette in your interactions with other developers, users, responders, etc. Strive to understand their point of view that may bias their preferences.
  5. Understands the client. Let the system adopt to their ways of doing things and not the other way around.
  6. Implementation biases and commercial interests should be avoided as much as possible in the solutions you recommend
  7. Actively share your knowledge and best practices with other projects and encourage reuse
  8. Try your best to help but work towards not becoming a bottleneck or single point of failure during a disaster response effort. You can do this by keeping your solutions simple (KISS), providing clear developer documentation.
  9. If you are volunteering to respond, make a commitment and make sure you understand what is expected of you and that you can commit that time for the expected duration
  10. If you know your tool has major points of failure, do not gloss over them but ensure you set that expectation with users during a response effort. It might still be the best option.
  11. Support and promote local capacity and diversity in your community and support infrastructure. Any form of harassment is completely unacceptable

Here are some comments.

1. "end users" is a technical term, "suffering of victims" is pejorative. It also implies that suferring is required before applications will confer any benefit. I would change this something along the lines of "Supporting affected people is our prime focus".
2. I think this is implied by 1, 3 & 8. Also, I don't think think that the focus on a H-FOSS/software implies the creation of a holistic* solution. A comprehensive solution incorporates many elements outside the domain of H-FOSS.
3. Title case is not required. "Open standards" is not a proper noun. Why not simply "We support open standards".
4. I'm not quite sure what this statement is intending, so it's hard to comment on how to improve it.
5. A client-focus muddles with your first principle. It introduces a principal-agent problem. There is also a risk of having this as a blanket principle, as it's often appropriate to train users to , rather than training the system to adopt to their way of doing business.
6. Why avoid commercial solutions? How about "Members shall disclose commercial or other relevant interests when suggesting a solution."?
7. Change to "our knowledge"?
8. This appears to duplicate the first principle.
9. I'm not sure about the wording here. I like the thought, but as you don't know what others' expectations of you are, it's impossible to comply with.
10. Too long. Change to "Be honest when discussing the capabilities of your software"?
11. The harassment element isn't necessary, as it duplicates 4. I think there is too much being bundled into this principle. I think it should focus on supporting local capacity for support novice software users.

Regards

Tim
__._,_.___
Recent Activity:
.

__,_._,___

Don Cameron

unread,
Oct 11, 2010, 3:59:36 PM10/11/10
to humanita...@googlegroups.com, humanita...@yahoogroups.com, Mark Prutsalis

Good morning team,

 

Wonderful to see this Code of Conduct under development, well done! – and great to see further discussion and input.

 

From a domain perspective (emergency management) the draft reads as a combination of a Code of Conduct and a Code of Ethics – May I suggest there can be value in delineating between the two? The Australian Computer Society ATM is facing a similar challenge and has just completed a rewrite of their Code of Conduct and Code of Ethics – The two are now contained within the same doc however separated by chapter to assist professionals working in various development areas.

 

Is there a working group for development of this code? – I would like to contribute if such exists.

 

Cheers, Don        

MARKETPLACE

Error! Filename not specified.

Error! Filename not specified.

Error! Filename not specified.

.

Error! Filename not specified.

__,_._,___

 

--
You received this message because you are subscribed to the Google Groups "Humanitarian-FOSS" group.
To post to this group, send email to humanita...@googlegroups.com.
To unsubscribe from this group, send email to humanitarian-f...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/humanitarian-foss?hl=en.

Chamindra de Silva

unread,
Oct 11, 2010, 4:41:58 PM10/11/10
to humanita...@googlegroups.com, humanita...@yahoogroups.com, Mark Prutsalis
Hi Don,

We are working on the humanitarian-ict WIKI which was setup after the Reliefsource WIKI that was hosted by Paul Currion that was affiliated to this mailgroup was archived. We have been using this WIKI initially it for the H-FOSS project group discussions, but it also is supposed to serve as a scratchpad for this mailgroup.

Everyone please feel free to add to:

http://www.humanitarian-ict.org/wiki/

You should be able to register yourself into it.

Don Cameron

unread,
Oct 11, 2010, 10:42:35 PM10/11/10
to humanita...@yahoogroups.com, humanita...@googlegroups.com, Mark Prutsalis

Thanks Chamindra – I’ll check it out.

 

Don

 

--

You received this message because you are subscribed to the Google Groups "Humanitarian-FOSS" group.
To post to this group, send email to humanita...@googlegroups.com.
To unsubscribe from this group, send email to humanitarian-f...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/humanitarian-foss?hl=en.

--
You received this message because you are subscribed to the Google Groups "Humanitarian-FOSS" group.
To post to this group, send email to humanita...@googlegroups.com.
To unsubscribe from this group, send email to humanitarian-f...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/humanitarian-foss?hl=en.

 

__._,_.___

Recent Activity:

Image removed by sender.


Image removed by sender.

Image removed by sender. Yahoo! Groups

.

Image removed by sender.

__,_._,___

image001.jpg
image002.jpg
Reply all
Reply to author
Forward
0 new messages