Cookies help us deliver our services. By using our services, you agree to our use of cookies. More information

Category talk:Oroboros QM pages

From Bioblast

Open questions

  1. Who is entitled to 'sign' the QM label with date? - Four eyes?

Schmitt Sabine (talk) 15:30, 7 September 2020 (CEST) The answer to the first question depends, in my opinion, on the answer to the second question. If we implement 4-eyes, then the whole Science team could be entitled to 'sign' the QM label with date. In this case, even if a very experienced member, as you or maybe Caro, has checked the page, I would ask a less experienced member, such as me, for 4-eye. Why? 1. A less experienced member can always check for typos/spelling, which might be easily overlooked by the expert. 2. This is an excellent training for members with less experience to become aware of details. Without 4-eye I would select 3-4 members of the Science team who check and 'sign' the pages. However, in my opinion, 4-eyes is always beneficial.

  1. How are updates handled for a page with a QM label?

Schmitt Sabine (talk) 15:30, 7 September 2020 (CEST) In relation to question 3 I would suggest to have sections. In case of an update I would have a new "signature" for this section. The "page history" enables the tracking of changes. Still, I would recommend that updates are communicated within the team via the intern wiki. Crucial changes, e.g. adaptation of protocols (sV-Chamber) could furthermore be communicated via alerts.

  1. Does the QM label always relate to the entire page, or should sections of a longer page be labeled separately?

Schmitt Sabine (talk) 15:30, 7 September 2020 (CEST) as mentioned above I would prefer sections

  1. Should we do one first round in which we check all pages, also in comparison to the respective MiPNets and maybe also DLPs? For sure, this would be a lot of work, but we recently had two examples with inconsistent information (MiPNet vs MitoPedia) and we need to check several MiPNets for printing, anyway. This should also reduce the number of subsequent updates.