Team:USTC Software/humanPracticeSafety

From 2010.igem.org

Revision as of 18:54, 27 October 2010 by Soimort (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Safety

safety concerns

As a software team, our team does not produce any typical biological safety or ethnic issues. However, we still take safety into account from as many aspects as possible:

1. Safety for programmers

Most of our work is mainly done in front of computers, which is not ergonomically to programmers as working in such environment may cause much exhaust and stress. Therefore, we made a series of regulations to guarantee they are not exposed to computers constantly for too long time and recreational area is within 10 meters. What is more, every time our programmers go to web labs, we make sure that there would be safety equipment as well as accompanies for them.

USTC Software hp fun1.jpg

2. Safety for public

We are aware what our software will bring to teenagers or youngsters, and our software is ensured that no violent or sexual scene or content is included. We also did a lot of work to estimate and reduce the possible errors or faults users may encounter in the future.

3.Safety for software

To better protect our intellectual property rights, we have consulted IPRs centre of USTC in case of future problem. We will restrict the use of our software and we will apply for a patent later.

4.Safety for campus

We are quite aware when we perform our work or lecture in campus, and no disorder or turbulence has shown during in the above activity.

5.Other safety concerns

(i) Our team made no new BioBrick parts (or devices), and no safety issues happened from this. (ii)No biosafety group or committee protested our project.

Suggestions for future development of safety in dry lab.

Although a lot of work is done to ensure the safety of programmers in dry lab, a lot of work still remains to be done. And here we present some brief ideas on how we can develop the safety for programmers.

1. In many conditions, programmers in a dry lab have to share places with experiment operators due to limited space, which may lead to underlying health problems. Therefore, we suggest that strict rules should be made to provide independent space for programmers.

2. We take it for granted that not only safety for programmers, but the safety for intellectual property should be taken into consideration. Thus we suggest that all codes and other achievement should be granted with copyrights before sharing.