La representación de las mujeres en los medios de comunicación

Balancing the interests was a boundary decision to embrace diversity and reduce the cost of governing the distributed resources. This was evident through the practice of facilitating collaborations, as shown in figure 14. The expansion of the community distributed the resources across multiple level of organisations: Kuali project, university, country, and Foundation levels. Coordinating distributed resources was one of the main governance challenges after the expansion:

“We sometimes pull in different directions. We have to be coordinated, and that’s not so easy. It's like herding cats” (S3)

150

Figure 14: Data Structure: Phase2-Setting Means of Collaboration

Therefore, the community members were urged to communicate rather than making assumptions. They were encouraged to attend face-to-face meetings (e.g. workshops, Kuali days) when possible, ask questions, and report any issues in Jira in order to get the community support. The following in an excerpt from one of Kuali documents:

“A KFS Developer is expected to:

-communicate rather than make assumptions ("when in doubt, ask") -when assumptions must be made to avoid impeding progress, communicate those assumptions

151 -raise any blockers immediately

-use the best communication medium available” (Document Name: Expectations of KFS Developer)

One of the major means of facilitating collaborations was through the use of standardised technical artefacts for coordination and communication. Tech3 summarises the main technical artefacts used during the second governance phase:

“…since probably the beginning of Kuali, we used Jira for issue tracking and confluence as a Wiki tool. There was a lot of documentation that was put out in the confluence. Over time, we also added Google documents, so we had a Google drive that was for the Foundation, for documents out in that spaces… We had fisheye for doing source code changes as well as doing code reviews”

It was apparent that the technical artefacts were utilised differently among different projects. Initially, standard technical artefacts were imposed on all Kuali projects. However, as they were used by different stakeholders, their properties were changed. For example, the intention of introducing Jira was to act a bug tracking system that directs the work:

“...they [i.e. team members] will report bugs, but often there are times where we break them down to sub-tasks, the assignee is the person who is doing the work. And then a watcher is somebody who gets a notification when action of the Jira occurs...So, simply, everybody relevant is associated with the Jira” (Tech2)

However, some user groups used Jira as an open forum:

“…but there have been time when Jira is just has been used as an open forum. If somebody found a bug and they said ‘what is going on with this and how is it fixed, can you tell us about it’” (Tech2)

152

Moreover, the teams utilised the tools according to the convenience of the user. The findings revealed that Jira and Wiki were used interchangeably in practice:

“Some of the subcommittee members and chairs are comfortable using Jira and actually put their enhancements in there. But, a lot of them are more comfortable using the Wiki” (Tech5)

In addition, Kuali Wiki was a web-enabled tool that was used to archive and share project documentations. Project teams used it differently depending on the maturity of the project and preferences of the users. For example, figures 15 and 16 illustrate the interfaces of Kuali Wiki for KC and KS projects respectively. Since the KC project was built on a well-established community, KC project was well documented and thus the KC view in Wiki, as shown in figure 15, provides more extensive list of documents. On the other hand, KS project started from scratch, and thus less developed in comparison to KC project, which is reflected in KS Wiki home page (figure 16). Moreover, it is evident from KS home page that the users prefer more interactive interface.

153

Figure 16: Kuali Wiki - KS View

Moreover, the use of the emails is also an example that illustrates that technical artefacts are not only mediators. The intention was to consider emails as the least reliable communication tool. This was evident in the documentations. For example:

“all communication mediums are not created equal

we value Face to Face communication over Video-conferencing we value Video-conferencing over Voice-only communication we value Voice-only communication over Text chat/IM

we value Text chat/IM over email

we value email over nothing

Use the medium with the most appropriate bandwidth for the need” (Document Name: Expectations of KFS Developer)

However, during the early days of the second governance phase, the community was heavily reliant on emails to ask for and provide support:

154

“There were definitely times during the implementation when we reached out to the mailing lists and said ‘hey we're experiencing this problem, have any of you has experienced that?’ and we got good feedback and good help. We also used the mailing lists archive in a number of occasions to see if there is something out their when we ran into a particular problem” (PM1)

Users across projects and countries heavily used emails to discuss generic and university-specific topics. In response to that high reliance on emails, the Foundation categorised the mailing lists into technical and functional emails to facilitate the discussions. Moreover, emails became a supportive tool for the other artefacts. The following are excerpts from email discussions where users refer to Wiki’s and Jira’s:

“According to the ""Contributing Developer Responsibilities"" on the foundation wiki

(https://wiki.kuali.org/display/KFSIMP/Contributing+Developer+Res ponsibilities), we are to include the JIRA number in the commit message. For contributions, do we need to wrap any of our changes in a comment with the same JIRA number?”

“Hi All, does anyone know the status of the above JIRA? We would like the ability to cut checks prior to their due date and was

wondering if anyone is currently doing this?“

The above illustrations suggest that the use of technology is not predetermined by its design. Instead, the properties of technology emerge in practice.