Cecile Barouk

At first, I was very overwhelmed and confused with the open source community. Taking small steps I have been feeling more confortable and I feel that I am now part of a community of contributors.

The biggest take aways from this experience are:

• Staying up to date with the industry.

I had very little insight on this at the start of the unit and I realised I was missing out. There are so many interesting projects people are working on. Staying active and constantly look for new things to take part in and learn brings a lot of value to one’s practice in art and computing.

• Versioning systems

My skills and knowledge about git and GitHub were not great before this unit. Now that I have learned proper practice, I see the why it is popular. As soon as I started working on other personal project I felt the need to use git. I even thought about it when doing projects not related to code. Being able to compare versions and track changes is very useful. I have been thinking about how to create a versioning system for music projects with a friend as a passion project.

• Collaboration

I feel more confortable doing team work with different ways of working. At first I felt it was pointless as my teammate was in a very different time zone. But in the end, working together still added a lot of value to our output and I just had to be more patient.

• Design

I realised too late I had not been careful enough about the accessibility of my design. This is something I will keep in mind for my upcoming work. The user research will take a bigger part of my time spent.

Thinking back on how this unit, I feel very happy with my journey. I think taking part in my process will improve my practice for all the reasons stated previously. I also feel more confident in my skills and it will be easier for me to approach other communities and developers in the future.

After working on the code, and getting feedback, I started the pull request.

https://github.com/LAION-AI/Open-Assistant/pull/3015

I included an explanation and a screenshot. This request was merged very quickly. I would have liked to have a bit more discussion with the code owners but I guess they are very busy.

The code reviewer gave insight on a modification that should be done to make it better. I just applied what was told.

It feels very nice to see my contribution live on the website.

Because I got a but bored while waiting for my teammate to answer, I decided to take another issue. I feel like this is a good way to adapt to other people pace. instead of getting frustrated I just work as much as I want to on my side and she does the same.

I saw an issue that was about debugging some part of the login in process for users.

https://github.com/LAION-AI/Open-Assistant/commit/d8d6613a8b6c32dc7707f4191c42ef638228ce19

This was a very small commit that just kept me busy. I really enjoyed practicing those skills with this issue. Debugging is my favourite activity in coding because it really challenges one’s logic and knowledge about the code.

Topic 1

Topic 2

Topic 3

Topic 4

Topic 5

Process

Process #7: Extra issue – Cécile’s blog (arts.ac.uk)

Process #8: Pull request – Cécile’s blog (arts.ac.uk)

Process summary – Cécile’s blog (arts.ac.uk)

Introduction:

User testing and community feedback are valuable tools for good software development. They can provide insight and different perspectives on a problem to find a solution to implement. The variety of user giving their feedback can also avoid accessibility issues. In this article I will look at how User testing and community feedback can be implemented in software development and how they apply my contribution.

Case study:

The Oculus Go is a good exemple of lack of research about users. Arwa Michelle Mboya Worked on a project where she had to make people wear the headset to take part in a VR experience. She realised that black hair was affecting the user experiences as the headset was not designed for the diversity of African hairstyles. The headset broke many times and participants struggled to get it on. Arwa Michelle Mboya then decided to design her own attachment. This accessibility issue is very important as marginalised communities access in technology is a broader issue that still needs to be addressed and worked against. It could have been avoided if black people took part in usability tests during the design process of the headset (Mboya, A.M., 2020).

My contribution

What I did

During my contribution, I was very insecure about the quality of my design. To feel more confident, I decided to ask for community feedback. I posted a message on discord asking for opinions on it.

All I got back was a thumbs up. It is difficult to work on this feedback so I decided to also add the screenshot to my pull request as a demo and say it is just a proposal. In the end, I got merged without much feedback.

I was also constantly sharing my work in progress with the other person I was working with. This turned out to be very useful but two sets of eyes still wasn’t enough. I felt a bit disappointed as I was looking forward to responding to feedback to create better content.

What I could have done

On the other hand, I haven’t looked at potential accessibilities issues in the design. As the change I have done is very small. I didn’t think it would be necessary to research users. Thinking back on it, I think I should have as making sure design is inclusive is very important. Even if it is just a button. for exemple in this design:

The contrast is quite low and there is important text stating the function of the button in the middle. I tried to view it through multiple types of colour blindness and it was still readable. But people with contrast sensitivity issues may struggle when reading this.

Conclusion

Learning about the importance of user testing and community feedback in class will affect how I work with design in the future. It was useful to observe and experience this part of the design in software development. I also got insight from thinking back on my process and understanding what I could have improved.

Mboya, A.M. (2020). The Oculus Go wasn’t designed for Black hair. [online] MIT Media Lab. Available at: https://www.media.mit.edu/articles/the-oculus-go-wasn-t-designed-for-black-hair/ [Accessed 2 Jun. 2023].

‌

Intro to versioning software

Versioning systems also called version control systems are softwares that is used to track and manage changes made to files. This article will look into the different aspects of these systems and how I have personally made use of them for my contribution.

Using version control when working on code has a lot of benefits. It makes a complete history of modifications available to everyone that’s working on the project. It is then easier to find where bugs are coming from and who to go to to fix the issues.

This history is also very useful to collaborations as: changes are visible and people can write extra comments about what they have done and why. The feature that makes is essential to collaboration is the ability to work on a personal branch to fix specific issues. The user is then able to merge changes to the main source code. This allows for developers to work separately at the same time. The workflow is then more efficient and less conflicting. Another aspect of the collaboration is the review. When someone gives a proposition to fix an issue and opens a pull request, the code will be reviewed by other developers and some feedback may be given to improve the quality. Having multiple eyes on a piece of code can be necessary for making a good piece of code.

It also has a good workflow for the enhancement of the project as the integration of new code is continuous. People can decide to fix an issue at any time and it will be deployed when it’s ready and approved.

And finally, it is good for keeping a project stable as if an issue comes up it can easily be reverted to the previous version of the code. The versioning software creates backups of the projects as all the changes are tracked. The risks arising from accidentally deleting, or breaking a piece of code are minimised. Experimentations that are thought to be risky can be done on a separate branch allowing for developers to have a safe space to innovate and try new interesting features.

For this unit, we have used Git and GitHub. After getting introduced to the proper way of using these tools, I started using them for my contribution.

GitHub

I used GitHub to find the project I collaborated to first. Because it is so popular, I was able to brows the projects and find this very interesting one.

I then found my issue and got to know the project’s specificities. I found that the features around community management are very useful to keep a project alive. I was able to ask questions to code owners easily and check people’s profile to get an idea of what background contributors had.

I also think the features around safety are good. The access and permissions are managed by the code owners. It has incorporated vulnerability checks. That feature made me feel much safer when working on the project on my own machine.

Git

After forking the project, I started using Git while working on the code. I used Git as a command-line tool to track the changes I made to the code.

I started by having to always have the cheat sheet with me while working on this unit but after some time it felt easier and more confortable.

I also used the git add-on in VS code and it made it much easier to see changes and keep track on the work done by me and others. The commits are visible just by hovering the code and there is an easily accessible commits’ history on the left of the working space.

Conclusion

I was very happy to get more comfortable with that tool because I think it is very useful to use it on personal projects as well. I noticed that right away after working on this unit I felt the need to use versioning software on every project.

GitHub Docs. (n.d.). Getting started with GitHub. [online] Available at: https://docs.github.com/en/get-started.

‌

Introduction to community engagement

When we talked about what is important to an open source project in class, the topic that came first was community.

All open source projects have their way to keep their community engaged. It is important to do so as it is the community that keeps the project alive. I contributed to the Open Assistant Project, In this article I will explain how I came around understanding and taking part in this community.

Study of the projects community (link to in class teaching, channels management, Bus factor)

When seeing the GitHub page of the project, I found out that is is part of a bigger organisation called LAION AI that does research around artificial intelligence. After deciding to contribute I started by observing how the community functions and exploring their different channels. It was important to listen first to gain confidence.

This project uses different channels to gather interest and make the community grow.

This community mainly uses Discord to discuss and help each other.

There are channels for different topics and languages. This server is very active, users discuss different ML models data sources and other topics important to the project and they can also find people speaking the same language easily to talk together. The good organisation of this server makes the communication effective and it helps the project develop faster.

I noticed a lot of respect and mutual help between users. This is also important to the enhancement of the project. Users can ask for help and get support from other users without feeling pressure while doing so.

Community and contributing

When contributing I had to use some of these channels and communicate with members. I only had to use Discord and GitHub.

• Help from members (advice, feedback, criticism)

Being able to get help got very useful. I had an issue with one of the packages that was used in the project and I could get help on discord.

• Contributing together

I also used discord to communicate with the person I was contributing with. It was very useful to be able to call and work together easily.

• Recognition and appreciation of contributions/ respect

When submitting and asking questions on GitHub, The code owners were always very patient and thankful for any type of engagement and contributions which made me feel safe to send my code even if I wasn’t very confident about the quality as it was my first pull request.

Conclusion

The community around the project has been very useful to my contribution. I also saw the importance of respect between members. Taking part in this community was very fulfilling and gave me confidence to do more in the future.

Introduction to Open Source Collaboration:

Open source collaboration is a very interesting way to develop software as the source code is accessible to everyone and people have freedom to enhance the software. Developers working together on a project a lot of benefits like mutual knowledge sharing, community feedback and quicker improvement.

Study cases: (In class exemples key takeaways)

In class, we had a look at multiple open source projects, Wikipedia is a very successful project that functions as an open source platform.

1. Presentation of the model

Wikipedia is an online encyclopaedia that contains articles about a wide range of topics. It allows anyone to contribute to its online pages. Knowledge is then easily shared and used by individuals. This collaborative model was successful for the website as it is popular, used and trusted.

2) Community engagement

We explored how Wikipedia manages its community to keep the collaboration open while ensuring the quality of the content. Each article has an history where all the changes are tracked. Volunteers contribute to writing the information and keeping it up to date.

Wikipedia has a vibrant and impressive community. It is important to foster community engagement to keep the project alive.

There are many events and meetups organised by the community. All the events are listed on a page per country (Events – Wikimedia UK). Contributors also get a sense of belonging and community from contributing to articles.

3) Wikipedia’s collaboration tools

To facilitate collaboration, Wikipedia uses an online platform that allows users to create new content and articles, edit existing ones and revise community changes. This is all done in real time and is intuitive enough for anyone confortable enough with Wikipedia to contribute. There also is a “Learn to edit” page that can help user to get started with their contribution.

Some volunteers also take part in the creation of Bots to maintain the website. Most of the bots work as quality maintainers, for exemple: ClueBot reports and reverts vandalism detected on articles.

5) Limits

Although Wikipedia is open for anyone to edit, it doesn’t push for diversity. There is an article on the Wikipedia community: Wikipedia : Wikipedians . We can see that less than 13% of contributors are female. The huge gender bias in Wikipedia has its own page Gender gap – Meta (wikimedia.org) and is addressed by many organisations, researchers and the Wikimedia Foundation themselves.

Conclusion:

This case study on Wikipedia gave be really good insight on how to approach open source collaboration. The popularity of Wikipedia shows the importance of engaging the community, inclusivity and good contribution tools. It also shows that it is important to address bias and take action against it.

Opensource software completely challenged the tech industry strategies on working on projects. It allows individuals to contribute to projects they are using, and passionate about. This aspect of open source is defined by the license used for the project. In this article I will share about my experience contributing to a project with the Apache License and the importance of licenses.

Open Source Licenses define the terms and conditions under which the project can me used, modified and distributed (Open Source Initiative, 2022).

We explored the different types of licenses in class and I was curious to see how projects would choose to apply OSI approved licenses to their projects. The projects goals have to be clear when making this choice.

The license of the project I contributed to (Open Assistant) is the “Apache License 2.0”. It is a popular license part of the OSI approved licenses.
The creation and development of the Apache Software Foundation started in 1993. Since then, they have released three versions of the license. The currently used one is the 2.0 version.
This license is a permissive license, it allows to use, modify and redistribute the software. It also gives right to relicense within license compatibility. This makes it very flexible and interesting to work with(Apache.org, 2019).

Before contributing to the project I had to understand the License so I read it at this link: https://www.apache.org/licenses/LICENSE-2.0

The different sections cover the topics of :

• Redistribution, It is allowed to redistribute copies of the project or modified copies of the project under certain conditions. The main ones are:
  This license has to be given with any copy.
  If changes were done, they need to be notified.
  All of the copyrights and trademarks from the source need to be retained.
• Contributing: Any contribution will be under the terms and conditions of this license unless stated otherwise.

And other topics such as how to deal with trademarks and the absence of liability between contributors in case of being in tort.

This license allowed me to contribute to the code confidently by: forking it and running it locally on my machine and modifying that code. The license also ensured that my contribution will benefit the community and allow other contributors to modify my work and keep improving the project. As the presence of this license gives a legal framework to explore the project safely, it has an impact on the community. The community of this project was very active and a lot of programmers felt happy and confident contributing to this project.

In conclusion, contributing gave me a space to think about licenses and freedom to experiment and learn within a community of developers of different level. The choice of a permissive licence such as Apache raises questions. This choice depends heavily on the goal of the project but I personally think I wouldn’t use this type of license for a project for multiple reasons:

• Maintenance of copyleft: I think this aspect is important to an open source project. Allowing users to distribute under proprietary licenses does not allow the project to keep its freedom and compatibility with other open source projects.
• Maintenance of a cohesive community: I think a cohesive community is very important to an open source project. allowing to create fragmentations of the project under proprietary licenses could create a competitive environment.

For those reasons, I feel more confortable using a copyleft license such as the GNU General Public License.

Open Source Initiative. (2022). Licenses. [online] Available at: https://opensource.org/licenses/.

Apache.org. (2019). Available at: https://www.apache.org/licenses/LICENSE-2.0.