DEV Community: Isabel Costa

How to find Open Source projects to contribute

Isabel Costa — Sat, 11 Jun 2022 02:20:55 +0000

I often get asked about how to find Open Source projects to contribute to. In this post, I’ll show you where you can find these projects. You can use these tips and adjust your search depending on what you are looking for in terms of the type of project you want to contribute to, the skills you want to practice, or the cause you want to support.

Projects you already use

If you’re a developer, most likely you have encountered libraries, frameworks, or programming languages that are open source. In case you use packages from NPM in your projects, you can find on the package page the link to the project's source code. Take the example of the react-kawai package which points to the miukimiu/react-kawaii GitHub repository. Same works for Python packages from PyPI. Take as an example fastapi package that points to tiangolo/fastapi GitHub repository.

Some programming languages are developed in the open source community, where you can look up the source code, pull requests, and discussions around it. An example of this is Python language where you can see pull requests being merged into the source code.

Here are a few random projects I’ve used before which are open source:

fastapi, a web framework for building APIs with Python;
python, the programming language;
scala-exercises, website to learn how to code in Scala;
flask-jwt-extended, Flask extension that provides JSON Web Tokens (JWT) support;
forem, software for building communities which powers dev.to;
jogo-das-profissoes, a Portuguese web-based memory game for children to learn about different professions;
Zulip, a team collaboration tool that can be used for open source discussion forums.

You can look at the issue tracker of the projects’ source repositories and see if there are any issues you can work on.

Interacting with a project as an end-user gives you a great perspective to detect bugs or desirable features that other users of the project appreciate. So you can even open an issue to report a bug or suggest a change to the project, which if validated you can potentially be the one solving it. Keep in mind that reporting useful issues is already an open source contribution.

Now, I want to highlight that you may use a project in another role other than as a developer. For example, if you are using an end-user application (using a real-time chat app, like Zulip, to communicate with other people). You can still find the project source code repository, and contribute in many ways.

Open Source initiatives

The way I got started with open source was via an initiative to incentivize people to contribute during December, 24 Pull Requests. I decided to make a first small contribution using Markdown, which you can check out at FrancesCoronel/hire-me/pull/9 on GitHub.

Later, I participated in another program called Google Summer of Code (GSoC), which helped me learn a lot about contributing to open source. Participating in these programs, was the way I got involved with open source.

Some time ago I wrote about open source programs and initiatives such as Google Summer of Code, Outreachy, and Hacktoberfest among others.

For Hacktoberfest, you can find these projects mostly during October. Projects and issues participating will have the “Hacktoberfest” label. For 24 Pull Requests, you can find projects listed on the page while the program is active in December.

What I usually suggest with regards to finding open source projects, is to look into organizations that have been participating in Google Summer of Code and Outreachy. Projects and organizations that participate in these programs tend to have a structure and clear guidelines on what work is available to be done so that the organization is prepared to receive participants and mentors during the program.

On the GSoC website, you can find recognizable names in the open source world, but also other organizations which were still eligible to participate. You can find organizations with very different types of projects, for example, projects related to hardware, applications for supporting social causes, developer tooling, security, etc… To get an idea, take a look at past accepted organizations that participated in GSoC this year or in 2021, 2020, 2019, 2018, and so on.

Here are a few organizations that I saw on the organization list ranging in categories: LibreHealth, Postgres, NumFOCUS, Debian, Open Food Facts, and The Tor Project.

Aggregators of projects and issues

Some websites aggregate open source projects or issues to make the process of finding projects to contribute easier. Some examples of these are Up For Grabs, CodeTriage, Ovio, etc…

Sometimes you might also find repositories that contain only informational content, and some, in particular, will have a compilation of projects. For projects in the Portuguese community, there’s a nice collection of Portuguese open source projects at the OldMetalmind/PortugueseOpenSourceProjects GitHub repository.

Additionally, you can find sometimes posts on the dev.to community where maintainers may be promoting their open source projects and specifically asking for contributors.

GitHub Explore

Another tool that can be useful to know, is the GitHub Explore feature that can highlight projects that can suit your skills. You can find projects grouped in collections or topics, or that are trending.

Some Collections that I noticed are government apps, made in Brazil, getting started with machine learning, made in Africa, …

Topics are like tags, which can be useful to find projects related to a specific tool, programming language, or type of project. Topics are usually explicitly set on a repository by the maintainer. During Hacktoberfest maintainers will add the Hacktoberfest topic to their projects to indicate they’re participating in the event. As an example, to find repositories with the Python topic you can go to github.com/topics/python.

Now that you know where to find them…

Be aware that once you find a project you’d like to contribute to, it’s possible the project is no longer being actively maintained. So even if you wish to contribute directly to it, there may be no maintainers to accept your contribution.

To understand if a project is active, check if there are recent conversations in issues and pull requests or commits to the main default branch. You can also look for any notice of the project no longer being maintained. Maintainers tend to leave a statement in the README or an issue, or even archive the repository if they are no longer maintaining the project.

When you decide which project to contribute to, make sure to read the Contribution Guidelines and Code of Conduct to interact with the project, the maintainer, and the project’s community in the way that is expected. This will make both your life as a contributor and the maintainer’s life easier. Also look for beginner-friendly labels, such as, “Good First Issue” or “First Timers Only” that are meant to help people find the first issues to contribute.

Another piece of advice I have is, that if you are just starting to contribute to open source, it can be easier to contribute to less popular projects, that may have less noise around issues and pull requests and the maintainer may be able to give you more attention. In any case, you can still look at popular projects that could have issues with the beginner-friendly labels I mentioned above. Although because of its popularity, it can be hard to contribute.

Know that you can find an open source in a lot of places such as GitHub, and GitLab, however for certain projects, the organizations that maintain it keep the source code hosted using their infrastructure. An example of this is the Android open source project which you can find here.

I hope this helped give you an idea of how to find open source projects! Often when I contribute to projects that I’m not the maintainer of, it’s because I stumbled on a problem in a project, that I knew how to solve and noticed no one had reported yet.

I’ve been a contributor, mentor, and admin in Google Open Source programs

Isabel Costa — Thu, 09 Jun 2022 23:04:20 +0000

I participated three times in open source programs created by Google Open Source. I participated in two editions of Google Summer of Code (GSoC) and one edition of Google Code-in (GCI). For all of these programs, I was part of AnitaB.org Open Source (previously, Systers Open Source).

All of these programs aim to help people get introduced to open source in a structured way. GCI was aimed at pre-university students (ages 13-17). GSoC was initially aimed at university students or recent graduates, before opening up in 2022 to all newcomers of open source.

My participation in these programs was:

Google Summer of Code 2018 Student (now referred to as GSoC contributor);
Google Code-in 2019 Mentor;
Google Summer of Code 2020 Organization admin.

I went through a full program cycle :) I’ll briefly summarize my involvement in the programs.

Google Summer of Code 2018 Student

In 2018, I applied to be a GSoC student with Systers Open Source (now called AnitaB.org Open Source). That is where I started my journey in these organization-guided programs.

In this program, I proposed a new project called Mentorship System, for women in the community to mentor each other via 1:1 relations. For this project, I developed both the backend REST API with Python - anitab-org/mentorship-backend - and Android application with Kotlin - anitab-org/mentorship-android.

The program was divided into one community bonding phase and three coding phases. During the program, I had 2 main mentors and one admin assigned to me. In the final phase, I got an additional mentor. My mentors would review my work (mostly code) and guide me on how to contribute in an open source environment and how to plan the work properly in our weekly sessions. The admin would oversee the project development and also act as a mentor. I learned most of what I know today about Open Source communities from this admin, who still mentored me beyond the program.

At that time, I did two presentations about my experience, which are available on Youtube:

After this program ended, I continued as a maintainer and contributor to the projects I created.

Google Code-in 2019 Mentor

In 2019, I wanted to participate as a mentor for GSoC, however, the community did not participate as an organization in GSoC that year. So I continued as a maintainer as usual for the Mentorship System projects. Then in December of 2019, we were accepted as an organization for GCI and I participated as a mentor.

As a mentor, I would create tasks and help participants contribute to Mentorship System, in multiple categories of contribution including Documentation, Coding, Quality Assurance, Design, and Outreach/Research. As the person that was the most knowledgeable about the project, I also helped other mentors understand what tasks could be brainstormed in different categories.

What I loved about this program was about promoting different types of contributions. The tasks were varied and we got so many good ideas to improve the project beyond code. I also really liked the fresh perspective other mentors would bring to the tasks brainstorming, as most weren’t familiar with the project, but still came up with ideas I wouldn’t come up with. I also learned from some participants who would come up with additional ideas for the project, outside of the GCI scope.

Here I also learned about the importance of being careful with working in a community with underage contributors. The community manager at the time (my GSoC admin) was very thoughtful about how to include the underaged GCI participants in our community forums. This led us to move from using Slack to start using Zulip, which allowed us to use features such as disabling private messaging and allow for people of any age to join the platform.

Unfortunately, this program ended in January 2020, after running for 10 years.

Google Summer of Code 2020 Admin

Finally, as GCI 2019 was finishing, applications to become an admin for the community opened. I applied, was interviewed, and then got accepted!

So I started as an admin at AnitaB.org Open Source in February. We applied to Google Summer of Code again and got accepted! At that point, admins (including myself) worked on creating applications and processes for students and mentors and preparing the projects for the program.

My experience was a mix of being a mentor and an admin, however, my main priority was acting as an admin. In short, my responsibility, shared with my co-admins, was managing the student projects, the program, and our community. I learned about how much can go into participating as an Organization in GSoC. I loved my experience as a student back in 2018, and here I saw all the effort that admins had to put into it to make it run as smoothly as possible.

I managed a team of 4 members - 1 student and 3 mentors. The project was BridgeInTech. Interestingly, this was also an original project proposed by the student, I could see a lot of what I went through with this student (who was amazing to mentor). Part of managing the team meant I would meet with the student once a week (at least), with the mentors on a bi-weekly basis, and with the whole team every week (project weekly meeting). The process was the same as I got as a student.

I must say participating as an admin, was a great experience, much because of the documentation of previous GSoC participation, program materials (e.g.: onboarding slides, past applications content, …), and the great amount of experience that my past GSoC admin had with this program. To have an idea, part of the work admins did was: students and mentors applications management; interacting with aspiring participants who get involved way before the GSoC application started; managing and supporting mentors who would help review the student proposals; onboard selected students and mentors assigned (both involving async and sync communication).

I’m so grateful for getting to experience these programs and different roles! It taught me most of what I know about Open Source which helped me so much in my career and also allowed me to find a way to give back to the tech community.

4 zonas a personalizar do perfil de GitHub

Isabel Costa — Sun, 03 Oct 2021 16:09:47 +0000

O perfil no GitHub tem cada vez mais opções que ajudam a representar o nosso perfil como programadores e contribuidores de open source. Aqui vou mencionar umas dicas sobre como melhorar alguns aspetos do perfil no GitHub para que deixe uma boa impressão para quem estiver a ver o teu perfil (como por exemplo: um recrutador, um colega, etc).

Eu partilho estas dicas e mais algumas numa das minhas apresentações - “Make the Most Out of Your GitHub Profile” - apresentada em inglês. Ao longo deste post, usarei exemplos do meu perfil github.com/isabelcosta.

Secção com foto, nome e descrição

Se fores ao teu perfil pessoal, tens uma secção lateral esquerda. Aí terás um botão “Edit profile” que te vai permitir mudar a secção.

Ao clicares em “Edit Profile”, podes adicionar a tua pequena biografia, nome, localização, link para um website e a organização a qual pertences. A organização não precisa de existir no GitHub para a colocares lá (o campo é de texto livre). Podes colocar a tua universidade ou empresa onde trabalhas.

Se não tiveres um website, podes sempre usar outro link para uma página tua como, por exemplo, o perfil LinkedIn ou qualquer outro website que te represente, como um blog.

Gráfico de contribuições

Sabias que podes configurar as contribuições que são representadas no teu perfil? Podes mudar as definições do teu gráfico de contribuições para que mostrem quadradinhos verdes, mesmo para código que escrevas em repositórios privados. Às vezes, podes ter repositórios em que estás a trabalhar, mas que são privados. Estas contribuições podem ser refletidas ou escondidas do gráfico de contribuições. Se estiveres à vontade a mostrar que contribuis mesmo em repositórios privados.

O truque para veres se isto ficou bem configurado, é abrires o teu perfil no browser em modo incógnito e compararmos com o gráfico de quando estiveres “logada”.

Para ativares isto, perto do teu gráfico de contribuições, tens um botão “Contribution settings” e depois podes selecionar a opção “Private contributions”. Assim, as tuas contribuições privadas ficaram refletidas no gráfico, mas continuam privadas, ou seja, as pessoas que visitarem o teu perfil continuam sem saber os repositórios privados para os quais contribuem.

Fixar repositórios relevantes

No teu perfil, também podes fixar os repositórios que queres destacar no teu perfil. Se não o fizeres, o GitHub irá selecionar por ti os repositórios a destacar (se tiveres 50 repositórios, os que estiverem no teu perfil, podem ser repositórios menos relevantes do teu portfólio de projetos). Podes escolher destacar 6 repositórios no total para aparecer no perfil. E também os podes reorganizar.

Aqui também podes destacar repositórios ao qual tenhas contribuído com código, mesmo que não pertença à vossa conta no GitHub. Eu escolhi um repositórios de organizações para o qual contribui (exemplos: anitab-org e getodk).

Para cada projeto que tenhas destacado, não se esqueças de ter uma descrição nesses projetos. Isto porque essa descrição aparecerá junto aos repositórios fixados no perfil. Assim, consegues dar um contexto quando alguém estiver no teu perfil e os repositórios afixados.

README Pessoal

Agora podes ter um README pessoal no teu perfil, onde podes usar a tua criatividade para te apresentares da melhor forma. Atualmente, o meu README pessoal é bastante simples, apenas com um pequeno texto biográfico e alguns links para perfis externos. No entanto, consegues adicionar muito mais através de automações.

Para teres um perfil README, basta criares um repositório com o nome igual ao username da tua conta no GitHub (exemplo: se o teu username é “mariaf123” - github.com/mariaf123/mariaf123 - o repositório terá de se chamar “mariaf123”). O README desse repositório irá aparecer no vosso perfil. Aqui está o meu exemplo.

Aqui estão alguns exemplos de README pessoais que podes usar para te inspirares. Estes repositórios são todos de código aberto (open source), por isso, podes ver o código e reutilizar o que te der jeito.

abhisheknaiidu/awesome-github-profile-readme

Espero que este post tenha sido útil! Se quiseres saber de mais truques, também podes ver esta apresentação de 15 minutos sobre este tema - “Make the Most Out of Your GitHub Profile” :)

AnitaB.org Open Source profile README on GitHub

Isabel Costa — Sun, 03 Oct 2021 16:01:51 +0000

GitHub announced the other day, that Organizations can now have their own README.

I love this feature! So when I had the chance I created one for AnitaB.org Open Source community.

One thing I’ve learned from being involved with Open Source is that not all communities work the same way. Each one has its mission, way of working, and contribution processes.

Welcoming every type of contribution is one of our core values, as is being beginner-friendly. Having a README allows us to inform contributors of how we operate and how they can help us. Now we can show what the community is about right when a contributor finds our organization page on GitHub.

The first impression we want to pass to newcomers and our community is that they can contribute in multiple ways other than code if they want. So the first draft of our profile README aims to let our contributors know they can join us on Zulip and contribute to our community in various ways such as reviewing code, implementing features, testing our apps, reporting bugs, suggesting design improvements, blogging for our publication, etc...

Here’s our profile README 🎉 which you can check out at github.com/anitab-org (source code).

If you have an organization on GitHub and would like to add this feature you can read about it here: https://github.blog/changelog/2021-09-14-readmes-for-organization-profiles/.

Sync fork with the original repository using git

Isabel Costa — Sat, 04 Sep 2021 11:38:58 +0000

When you want to contribute to an open source repository, you usually fork a repository so you can do your changes and later submit them via a pull request. After forking the repository on GitHub, and cloning it into your local environment - git clone <forked repository url> - the repository will have a remote URL setup, usually named origin.

You can also do this using GitHub web user interface. Check out the docs! I already mostly use this option, but it’s always useful to know the basics of doing this with git.

To use as an example, I forked anitab-org/documentation repository into my GitHub account isabelcosta/documentation. When cloning the repository I used the SSH URL of my forked repository. The commands I’ll mention will be running against the repository’s default master branch.

First, check what remote URLs your project has set up with:

git remote -v

Here the origin configuration will have the URL where your forked project is on GitHub (notice that my isabelcosta account username is there). I am also inside the root directory of the local clone of my forked repository.

~/dev/documentation > git remote -v
origin  git@github.com:isabelcosta/documentation.git (fetch)
origin  git@github.com:isabelcosta/documentation.git (push)

Now you can add the new remote repository link to your remotes. The upstream keyword is an alias for the original repository remote URL (replace <url of original repository> with this URL). You can pick another alias if you prefer.

git remote add upstream <url of original repository>

Notice that in this case, the link is pointing to anitab-org account - where the repository was originally forked from):

~/dev/documentation > git remote add upstream git@github.com:anitab-org/documentation.git

To confirm the remote repositories you have set up, the new upstream repository configuration should be there.

~/dev/documentation > git remote -v
origin  git@github.com:isabelcosta/documentation.git (fetch)
origin  git@github.com:isabelcosta/documentation.git (push)
upstream    git@github.com:anitab-org/documentation.git (fetch)
upstream    git@github.com:anitab-org/documentation.git (push)

With this setup, you can now sync your repository locally using pull/fetch code from the original repository. Here’s an example where I am pulling code from the original repository into my fork’s master branch:

~/dev/documentation > git pull upstream master
From github.com:anitab-org/documentation
 * branch            master     -> FETCH_HEAD
   85f3fdc..5854a22  master     -> upstream/master
Already up to date.

After updating my local branch, I usually also update the fork on GitHub. I push the new commits pulled from upstream to my origin forked repository (using the same master branch):

~/dev/documentation > git push origin master
Everything up-to-date

Commands summary

Check remotes: git remote -v
Add a new remote: git remote add upstream <original repository url>
Sync local repository: git pull upstream <branch>
Update remote forked repo: git push origin <branch>

You can find me on Twitter, GitHub and my personal website.

Contributing to Open Source in Quality Assurance

Isabel Costa — Sun, 21 Mar 2021 21:20:57 +0000

Did you know you can contribute to Open Source with Quality Assurance? Usually while building software, there is some component of quality assurance or testing involved, so that also applies to open source projects. When I think of quality assurance of a project I think of testing in general, which includes writing unit tests, integration tests, manual testing, performance testing, documenting test scenarios, ...

Contributing to Quality Assurance (QA) helps to ensure the overall quality of the project since it can help to detect bugs early and faults in how the feature was implemented.

Ways to contribute

So here are some examples of how to contribute to Quality Assurance of an open source project:

Test manually a pull request code before it gets accepted to be merged, to confirm the code is working as expected. Be creative! Try to come up with test cases for the feature being implemented that perhaps the author of the pull request did not think of. Examples: testing REST API, testing bottom navigation bug in android app.
Test the deployed version of the app and report bugs found by creating issues describing them! Provide as much information as you can so that maintainers and other contributors can confirm the bug, and also for developers to have the necessary context to look for a solution for it.
Write tests to improve test coverage of the project. These could be unit, integration, user interface, automation tests… Sometimes also, there could be enough code coverage, but some edge cases for a feature might not be covered in those. So be creative!
Reproduce bugs already reported through issues and add more context or information to those if you think it’s missing. You can help maintainers confirm if a bug was properly reported and makes sense.
Write documentation about test cases for the project. This can help new contributors learn how to use the project, and what are some use cases for it. Also can help other testers, do more testing and cover more scenarios. Example: quality assurance test cases for mentorship-backend.
Help automate tasks on CI/CD pipeline as enforcing coding style in code, run tests for the project, so that pipeline fails and signals to contributors and maintainers of the code changes of a pull request are up to standards.

Resources to learn more about Quality Assurance

There are 2 resources that come to my mind with regards to learning more about Quality Assurance.

Test Automation University - https://testautomationu.applitools.com/ where you can learn about Test automation specifically.
FreeCodeCamp has a certification for Quality Assurance https://www.freecodecamp.org/.

I would love to know more resources, so if you know more, let me know in the comments :)

Process at AnitaB.org Open Source community

When working on my Google Summer of Code project back in 2018, I tried to come with ways for other open source contributors, to contribute to the project by testing it. I asked for help in the community for people to test the application and report bugs found by creating issues. Here's an example of a bug reported where user registration was possible by sending empty values for certain required fields.

When contributing to Open Data Kit, I noticed that maintainers had a step while reviewing code, of verifying if my change was working on multiple Android versions. This inspired me to incorporate such steps in our community as well. These days at AnitaB.org Open Source we have this step as part of our Open Source workflow, in particular of the Pull Request lifecycle.

Our work related to QA includes:

A guide to contributing to Quality Assurance in our projects; We also have a PR test report template we encourage our contributors to use when testing a PR;
Once we have 2 approvals, we label the issue with “Status: Needs Testing” and wait for someone, other than the author, to run the PR code (or test the live app if there is a deployed version of the PR) and test what was implemented. In success, we label the issue with “Status: Ready to Merge”, in failure we re-evaluate the PR with the contributor;
We started exploring a test management tool called TestQuality to help us document test scenarios we already know and tested before;
We have a dedicated channel #quality-assurance on Zulip for general discussion around QA;
Writing automated tests, which includes UI tests and unit tests, user journey tests, …
We have deployed versions of some of our projects, which allows contributors to test the app, without running the app in their development environments. We also have apk artifacts being built through GitHub Actions for one of our Android apps being developed.

As per our experience in the community, people who were joining us were mostly interested in contributing as a developer, but eventually got interested and helped with this type of contribution. By learning how to test a project, you also learn how the project works. This can be an easy path to start contributing and getting familiar with the project and its codebase.

A huge thank you to Roshni Pattath who has been an advocate and mentor for quality assurance within the AnitaB.org Open Source community. I’ve learned so much from her. Also for helping me review this post.

If you are interested in contributing this way, we have plenty of work you could do in our community. You can check out GitHub and also join our Zulip!

You can find me on Twitter, GitHub and my personal website.

Dataclasses in Python are nice!

Isabel Costa — Sun, 14 Mar 2021 12:31:38 +0000

Couple weeks ago I learned about dataclasses feature in Python. This feature is a nice way to define classes in python. This was introduced in Python 3.7, in particular PEP 557. To use this feature make sure you are running python version 3.7 or above.

Previously, I knew about defining new classes in python using the self.__init__() function. Here's an example of me defining a class Youtuber.

class Youtuber:
    def __init__(self, name: str, categories: list[str]):
        self.name = name
        self.categories = categories

Now we can use less boilerplate code to define classes. There is no need to install a separate python library, this will come with python standard library (as long as it's > 3.7).

Here's how you can define these now:

from dataclasses import dataclass

@dataclass
class Youtuber:
   """Class for defining youtubers."""
   name: str
   categories: list[str]

In this example above, I am importing it first from dataclasses import dataclass and then defining it. I created a class definition and used @dataclass annotation to tell python how it should interpret this class definition.

Then I can create this in python, as I would do it anyway, regardless of using @dataclass:

Youtuber("Chris Stuckmann", ["movie-reviews"])

Here's how you can try this out, using 3 of my favorite youtube channels :)

youtubers = []
youtubers.append(Youtuber("Chris Stuckmann", ["movie-reviews"]))
youtubers.append(Youtuber("Double Toasted", ["movie-reviews"]))
youtubers.append(Youtuber("The Fitness Marshall", ["fitness"]))

for youtuber in youtubers:
    print(f"{youtuber.name}'s categories are: {youtuber.categories}")

Let's put this all together in a file called youtubers.py and run it! You can copy it from this GitHub gist I created. You should get this output:

$ python youtubers.py  
Chris Stuckmann's categories are: ['movie-reviews']
Double Toasted's categories are: ['movie-reviews']
The Fitness Marshall's categories are: ['fitness']

Hope you enjoyed this short article!
You can find me on https://isabelcosta.github.io/

That time I contributed to Scala Exercises website

Isabel Costa — Sun, 07 Mar 2021 16:54:05 +0000

As a beginner in contributing to open source, you might not be sure of how to start contributing. I want to tell you about a contribution I have made to an open source project I used.

Often I explain to people who want to start contributing, that they can look into projects they already use. This is what I did when I contributed to scala-exercises.org website content.

Identifying a potential contribution

I was working through FP IN SCALA exercises, from "Functional Programming in Scala" book, in particular, I was doing the Property Based Testing section.

I noticed there was a typo where the syntax for the scala language was incorrect. Instead of showing ||, which means logical or in Scala, it was showing \\ that does not show correctly what it should be.

I also noticed that one of the exercises' numbers was incorrect, in this case appearing duplicate. So instead of showing exercise 8.17 it was showing 8.18 when referring to problems from 8.17 section.

Looking how to contribute

So once I found what I could improve on the website, I looked at the project's contribution guidelines and noticed that the process was fairly simple and there was no requirement for creating an issue before sending a pull request (PR).

So I decided to create a pull request to it, one for each change since they address different concerns.

I checked where the code I was supposed to change lived, so I could make the change. This was fairly easy because the page with the exercises had a link to the file on the respective repository that hosts the code. This was visible in an "Edit exercises" button at the bottom of the page, as well as a "View on GitHub" button on the top of the page. You can check the page I changes here.

Contributing

I clicked the link, which took me to the file I need to change. At this point, I started the process of contributing. I forked the repository - creating a copy of the repository on my GitHub account. Then since the changes were fairly simple, I did not have to clone the repository to my development environment, I did the change using GitHub GUI (graphical user interface). There I edited the file then created the branch and committed the changes.

After changing the code, I submitted the pull requests for my changes.

Fix exercise 8.9 function name from "\" to "||" => scala-exercises/exercises-fpinscala/pull/55
Fix wrong exercise number for Ch. 8 => scala-exercises/exercises-fpinscala/pull/57

Eventually, one of the maintainers thanked me and merged my PRs. I also get to be in contributors mention in the page I changed :)

So as you see, I fixed 2 typos that improved the content of the website. My change helped the page content be more clear, to someone using the project. I loved doing this contribution.

You can find me on Twitter, GitHub and my personal website.

How to change last commit message

Isabel Costa — Sat, 21 Nov 2020 20:36:56 +0000

Often when making changes to code, I commit them and then have to change to commit I just made, either because I think the commit message could be better or I had to make a last-minute change to the code I wish to include in the commit.

Change last commit message

So consider I committed changes with the following command (-m to write one line commit message):

git commit -m "fix: big feature X"

Here’s how I fix the commit, using the --amend option.

git commit --amend -m "fix: small feature X"

In case I want to add additional code to the commit, I run git add <file> before running git commit --amend.

Verify new commit message

To check that it worked and I fixed the right commit I check the latest commit with:

git log --oneline

I use --oneline because I just want to see the commit messages, instead of also seeing the name and email of the author of the commit. You’ll an output similar to this, where you can see the last commit has the correct message:

1792519 (HEAD -> master, origin/master, origin/HEAD) fix: small feature X
701aa33  docs: add instructions to README
(END)

In my environment, this will open vim, which I close by typing :q.

Fix pushed commit

In case I already pushed to the remote repository the commit I want to fix, I force the push to remote to update the commit. Preferably, you are working on a feature specific branch, which does not affect the main one (in case this messes the git history for some reason). So this is what I would run, where <branch> is the branch you are working on (e.g.: master).

git push -f origin <branch>

Hope this helps you fix the last commit message.

Ficheiros base num projeto Open Source

Isabel Costa — Sun, 08 Nov 2020 00:42:18 +0000

Um projecto Open Source costuma ter uma base de ficheiros, que permite colaboradores perceber como devem interagir com o projecto e quais as expectativas de quem mantém o projecto (maintainer). Estes são os ficheiros base que projetos open source costumam ter.

Licença

A Licença de um projeto open source é importante para os colaboradores saberem em que condições podem usar o projeto. No que diz respeito ao tipo de licença que se deve escolher, isso depende do projeto. Eu sei que há umas licenças mais permissivas que outras. Há licenças que permite a modificação e reutilização, etc, desde que o crédito seja devidamente atribuído aos criadores do projeto.

Este ficheiro costuma estar na raiz do projeto. E normalmente tem o seguinte nome: LICENSE.md ou LICENSE.txt.

Há um website que explica diferentes tipos de licenças - choosealicense.com. Aqui podes tentar perceber qual o que se adequa melhor ao teu projeto open source.

Código de conduta

É muito importante ter um código de conduta num projeto open source. Isto permite aos colaboradores saberem que tipo de conduta é a adequada e a que não é aceitável na comunidade a volta de um projeto de modo a manter o conjunto de interações, na comunidade, segura e amigável para todos. Este ficheiro, também deve conter informações de como reportar violações deste código de conduta por parte de membros da comunidade, para que o ou a maintainer possa tomar as devidas ações.

Se quiseres saber de exemplos de código de conduta, podes encontrar um bom exemplo, já adotado por vários projetos, em www.contributor-covenant.org. Este modelo de código de conduta tem traduções em várias linguas, incluindo versão em português.

README.md

O README é o ponto de partida de um colaborador num projeto Open Source. É neste ficheiro que se espera aprender mais sobre o projeto, como a sua missão e descrição, instruções para ter o projeto a funcionar, etc... Por isso é super importante que haja informação relevante para colaboradores sobre o projeto e links para o resto da documentação. O formato e o conteúdo deste ficheiro pode variar de projeto para projeto, o que interessa é que novos potenciais colaboradores, encontrem informação necessária para explorar mais sobre o projeto. Há projetos em que o README representa a maior parte do projeto em si, por exemplo se o repositório for apenas conteúdo informativo como awesome lists (ex.: vinta/awesome-python no GitHub). Este ficheiro, encontra-se na raiz do projeto. Por vezes, podem haver outros tipos de README presentes em pastas do repositório, que podem explicar em detalhe informações relevantes sobre o conteúdo específico da pasta.

Guia de contribuição

O guia de contribuição, CONTRIBUTING.md, ajuda colaboradores a perceber o tipo de e os passos para uma contribuição bem sucedida. Os passos de contribuição para um projeto podem diferir de projeto para projeto. Na comunidade onde estou, AnitaB.org Open Source, nós pedimos aos colaboradores para criar uma issue antes de submeter uma pull request (caso a issue não exista). Isto pode ser útil para nós que por vezes temos muitas contribuições, e podemos assim validar rapidamente Pull Requests que são spam ou inválidas, e fechá-las. No entanto, já contribui para projetos, como na minha primeira contribuição para Open Source, no qual podia simplesmente criar PRs com as minhas sugestões de melhoria do projeto, sem necessidade de criar uma issue antes. Como maintainer, é neste ficheiro que se deve definir as expectativas que temos para com e dos colaboradores.

Dependendo do projeto, podes encontrar este ficheiro na raiz do projeto, ou em pastas específicas (exemplos de pastas são .github no GitHub, .gitlab no GitLab ou docs).

Modelos de Issue e PRs

Modelos de issues e de Pull Requests (PRs) pode ser útil para fazer com que haja consistência nas descrições das mesmas. Estes ficheiros, servem de exemplo e são usados no ato de criação das mesmas. No GitHub e no GitLab podes tê-las numas pastas especificas .github ou .gitlab, respectivamente, para as issues e PRs serem automaticamente preenchidas com os modelos, que depois os colaboradores apenas terão de editar. Como maintainer, isto será útil para que colaboradores prestem especial atenção às expectativas dos maintainers para contribuições. Nestes modelos podes ter uma lista de pré-requisitos de uma contribuição, que pode facilitar o trabalho de triagem das issues e PRs (exemplo: link para documentação regras de estilo de código, secção para descrever testes manuais feitos para uma nova funcionalidade adicionada, seção para incluir imagens tiradas das modificações a interface de utilizador como ecrã da aplicação, etc...).

Se quiseres um exemplo de modelos de issues, um dos projectos que mantenho tem diferentes tipos de modelos para issues e exemplo de modelo de descrição de PRs. Também podes encontrar diferentes modelos neste repositorio - devspace/awesome-github-templates.

Descrição e Tópicos

Descrição e Tópicos não são representados em forma de ficheiros, mas são igualmente importantes para a base de um projeto open source. Estes no GitHub, como dois campos que podes preencher sobre um repositório. Ambos os campos são das primeiras informações que um colaborador pode ver sobre o projeto. Este aparece quando o projeto é listado, sem precisarmos de estar na página do repositório. Por isso uma boa descrição e tópicos relevantes podem ser a diferença entre um colaborador decidir ver mais sobre o projeto ou não. Isto também se aplica a tópicos.
Como developer de uma certa tech stack, eu posso pesquisar projectos que usam uma tech stack específica. Mesmo não sendo developer, posso querer encontrar projetos de impacto social, e pesquisar esse tópico específico. Isto ajuda a um colaborador ter uma ideia de um projeto, antes de ir a página do projeto e também perceber se é algo para o qual quer contribuir.

Espero que isto te ajude se estiveres a começar um projeto ou a melhorá-lo para conseguires ter um projeto mais atrativo para novos colaboradores.

My First Open Source Contribution

Isabel Costa — Mon, 27 Jul 2020 23:08:12 +0000

For a long time, I thought about contributing to Open Source, but I felt I did not know where to start. As a software engineer, I wanted to learn and build a portfolio of work through contributing to Open Source.

Back in December 2017, I got the word of 24 Pull Requests, an initiative with a Christmas feel to it, where you can contribute to open source projects during the month of December.

When I found about this, I decided to look into it and see if I could contribute. To start I thought about contributing with a “low hanging fruit” sort of issue. Even though my main interest was in coding, I wanted to start with the documentation type of contribution. So I looked into projects made of markdown files and found fvcproductions/hire-me which is about providing resources and advice for people looking for jobs, such as interview tips, job boards, and other types of resources.

So after looking into this project I noticed that there was a job board that I knew that was not there so I saw an opportunity to contribute.

Next, I read the contribution guidelines which were very simple. The steps provided in this project guidelines were: 1. fork repository; 2. read contribution guidelines; 3. add my name to the credits section; 4. Open Pull Request; 5. Get pull request approved 🎉

So after I forked the repository, I added my changes and my name to the credits in the README, and submitted a Pull Request. Here’s my pull request #9!

Some days after the maintainer of the repository merged my PR and thanked me for my contribution! I was so happy that I finally managed to do my first open source contribution after so much time delaying it. After this moment, I knew the basics of an open source workflow and I could apply to other contributions.

Have you ever contributed to Open Source? If not, I hope this inspires you to get started :)

Images of People of Color for content creation

Isabel Costa — Sat, 20 Jun 2020 12:57:02 +0000

A couple of years ago I saw this great blog post from peopleofcolorintech.com about stock photos with people of color in it. I found this amazing! I never thought about using my blog posts or other types of public content to spread more visual representations of people of color.

After reading this, I became aware of the existence of pictures/illustrations I could use that include people of color in online content such as blogs, presentations, promotion flyers, etc. I understood I could use them as a way to increase the representation of women of color in online content, more specifically related to the Tech industry.

Since I became aware of this when I include pictures of people in my blog posts I try to always include people of color on it.

Here are three resources that I am always aware of when looking at stock photos for my blog posts:

I mostly use photos from WOCinTech Chat, but I always have in mind all of these resources. The cover image is in fact from there! You can find that image here.

Thank you for reading this, I hope you find these useful and consider using these resources when appropriate.

This was originally posted on Medium.

You can find me on GitHub, Twitter, LinkedIn, and my personal website.