Transparency vs Traceability

Mozillians
#1

I’m learning more about Agile for work and of course I can’t help but see how what I’m learning could be applied to my Mozilla contributions or problems I’ve seen here.

I’m currently seeing the word “traceability” used a fair bit, and it makes me thinking of discussions on sync vs async, having full videos and IRC logs of conversations available when we talk about transparency and “open.”

I don’t have much more formed, but I also didn’t want to lose it. I feel like it might serve us in our planning and processes if we were to address these two concepts separately, and it might help to be clear when something is serving transparency and when it’s really serving traceability. Traceability isn’t always necessary, and I have a feeling as I read more I’m going to be told it’s not always so important.

Would love to get input from people more familiar with the concepts.

#2

This is entirely relevant to the ‘Mozilla firehose’. We take the transparency part of open to heart to the extent that we put everything out there only to make it nearly impossible to understand what’s going on. And then we don’t stop to document anything in a coherent fashion to cut out the noise so that other people can follow along and jump in if they have contributions.

This isn’t just a participation thing, this is a whole organization thing. Cross-team collaboration amongst staff suffers as a result.

I’d go so far as to say that transparency without traceability in a large project (inolving more than 15-30 people) creates a non-open environment because it’s impossible to understand any effort because of the time commitment required to go through raw primary source materials. Project historians and documentarians are critical.

#3

Interesting. In early stages what I’m reading downplays documentation in favor of conversations. I think this is also why they downplay traceability - you learn what you need to from interacting with the project, be it a product or a team. I haven’t gotten into the meat of it yet though, so no opinions on how it applies, except the observation that Mozilla for a while now seems to try to push the idea of traceability as the golden rule to enable contribution over interaction. I am interested to get to the part where they explain their stance!

#4

I’ve never really thought about trace-ability as a component of working open, I more take for granted that something is traceable because it is open. But I like it. I like the idea of building a fire-ladder in the firehouse :wink:
Could it be that trace-ability is ensuring that you share in the right places (physical location) AND also take an extra step to recognize the value to others and connect them - “did you see this?” Openness then can be described as the ability to receive information with an intention to distribute information beyond yourself, through communication (talk, email, chat) where that seems beneficial AND the act of sharing your own work. (simplified)

Guys - I am thinking about a workshop on working open: https://github.com/mozilla/participation-org/issues/284 would love your thoughts on key components, and maybe we also innovate on our message by using ‘traceability’? Making this up of course :smiley:

#5

Replied on github!

I’m seeing that traceability is an issue of scale and context. For me transparency is being able to understand why a decision was made while traceability is being able to trace the whole path of the decision making/implementation process for each thing. I think a good example might be why X was chosen over Y. It’s not so important that people can see the conversation where X was chosen. It’s important that people know why X is a good idea. Y might also be a good idea, but does understanding why it wasn’t chosen matter as much as understanding that X is a good thing and it’s working?

What I’m reading also talks about using conversation instead of documentation. I think in this example they would want people to just have a conversation about why X was chosen over Y instead of creating extra documentation for people to try and trace the answer themselves. Most of the time, that conversation is unlikely to happen, so why create the documentation just in case?