Outreachy Wrap Up!

14th of August marks the end of my Outreachy Internship with Mozilla. During this short 3 months, I have learnt a lot about how to network, code, write blogs ;), and generally how to engineer better. It is truly an experience I will cherish. Thanks to my wonderful mentors, Dustin, Eli, and Hassan for picking me among all other competitive participants and for all the guidance throughout the project workflow despite the huge time zone differences, the project won’t be a success without you guys.

It’s been more or less a week since the last day of my Outreachy internship. Reflecting back, I had never once imagined working with awesome bunch of people. I loved everything about my simple, beginner friendly project, Codetribute, Mozilla, Firefox and most of all, my amazing mentors and the people at Mozilla, so much so that I plan to just hang around as a volunteer even after my internship ended.

I feel like I gained a lot from this internship. I learned how to collaborate with others on a large open source project during the application period, learned how to write code with good practices, learned to google issues, and most importantly, I learned not to be afraid to ask questions, thanks to my mentors who were super patient and very kind to me. Having mentors like that and being able to learn by asking any questions I had, without any fear of judgement, is what I liked most about my internship.

While it was my Outreachy application and project that introduced me to things mentioned above and taught me how to be a good contributor, I believe it was what I choose to do after my internship ended, that will expand my education. I would like to contribute during my free time, after settling down to my new workplace, Shopee.

I have also received tons of questions through FB, Instagram, Linkedin, and emails about Outreachy, my technical skills level when I apply, how to start, what project to choose, and what criteria they use for selection. Thus, I decided to create a separate blogpost for it in the form of an Q & A while I still remember all those details. But still, I believe nothing beats checking their site regularly as it contains the most updated information (at least more updated than mine) about the administration process.

Anyway, if you are interested to apply for Outreachy, start early! Visit this Codetribute site, find issue to work on, introduce yourself, and ask to have the issue assigned to you! All the best! Ping me if you need help setting up Git, I will try my best 🙂

Before I end my post here, I’d also like to extend my thanks to the organizers of the Outreachy Program, the Outreachy coordinators at Mozilla (Lizz and Dustin) and friends who encouraged me to apply. Thank you!

Advertisements

Week 8 Update: Enhancements, Updating Project Data, Integrate with Bugzilla Done!

Hi guys, last week was my 8th Week as Outreachy Intern, time flies! We have received some PRs and email reply from the Project owner regarding their entry in the site. Some feedback we have received along the way are:

1. Group the Firefox related items together / reduce their amounts
2. Add language filter ability
3. Bigger text for description and smaller for tags
4. Drop the “Project Introduction” title and maybe just use the first title from the introduction. This would reduce the vertical space taken up as well.
5. Make the Expansion Panel default to close

Some project that has updated their entries are Taskcluster, MDN, Firefox UI, Telemetry Dashboard, and Sea Monkey. We are now able to find bugs and their updated project information in those project pages.

Some enhancement I do last week:

1. Add the info button beside the summary
2. Work on the display for Card which might be more suitable for mobile view
3. Close the Expansion Panel by default
4. Handle same github repository with multiple tag
5. Fix the link icon not to shrink when the text before it is too big
6. Remove wrapping from all table cell (now it wont create new line)
7. Fix table horizontal scrolling issue (when you scroll horizontally, only the table should change)

I am trying to do some experiment with the front page UI and thinking of adding some SVG to beautify the page, while doing the display bug using Card. I am also thinking of whether we should display bugs based on language query without selecting the project.

One of the UI I try to experiment with

Week 7 Updates: Filtering and Enhancement!

Hello guys! I’m back again! I returned home (Indonesia) this week while continuing my work remotely (despite the internet connection 😦 ).

This week I added several filter options like filter by tag, assignee status and component name. I do it this way because one Mozilla project might have very multiple components with totally different skill sets needed. Some may also use the tag to categorize the difficulty level or tech stack needed. The tag filter has landed, now you can click on one tag and it will filter to display bug with those tags. To deselect, click again on the tag / click a different tag.

I also work on the I’m Feeling Adventurous button that will randomly give you one task from a project. It might need more advance algorithm later on which bug it should give you, but it landed for now. I also work on several enhancements on the Error Panel (padding, text color, and button color) and make it tab-able for the project card. We try to land the bugzilla Graphql fetch soon YAY! We also try to create a guide for people to add Project’s .yaml file which is displayed throughout the site.

So I think that’s all for now! I want to try to socialize this project to the repo owners, wish me luck!

Week 6 updates: Colored page

All Hands has been amazing, I met tons of people working on things I have yet to understand during meetings, talks, or even breakfast (I followed my mentor’s advice to sit on random table)! I really like the environment where you are encouraged to ask question and everyone seems to discuss approach not only to make things work but also to make it work well, scale well, easy to maintain, and reusable by using the best approach they know at the time.

I think it has been one bad habit of mine that I try to break, that is to think ‘it is ok as long as it works’ and choose approach without considering its long term effect, especially under deadline, which results in poor, unreadable, not maintainable work, be it the problem sets I do as exercises or the code I submit for assignments, most of which become unreadable later.

The stickers I managed to secure! Does any of you know what sticker is the o-shaped circle with white filling and a little bit of red in the circumference (The one below Taskcluster’s)? Comment down below :p

After All Hands, I decided to redesign the project page and add theme to the system. Check it here. I also try to add some filters and try to pop up the question of ‘Should there be a leader board?’ in the mailing list.  On one hand, it gives motivation for contributor to continue working on bugs and serves as a reward and appreciation. Yet on another hand, it may discourage people to contribute since we only mark people that solve bugs not the one that raise it and review it. Moreover, the number of bugs one solved may not be a correct measure of how much one contribute due to difference in difficulty level and how much knowledge needed.

We also agree that title may not give enough explanation of the bug / issue and try to opt for a way to standardized a tag in the comment field in Bugzilla that shall be the explanation that contains how to get started and which repository you should look at.

I plan to do not only sorting but also filtering for the bugs. I also plan to make the display more responsive for mobile by providing choice to display Card or Table, which is nice but require wider screen.

Fifth Week as Outreachy Intern: Attending All Hands

Last week was my fifth week as Outreachy Intern. I started the week by flying for 15 hours to San Francisco to attend my first Mozilla events, All Hands and also to talk and discuss about my projects in the meetings organized by my mentor, Dustin.

I spent the first day checking in and while I wait for the Welcome Reception, I spent the day with my friend from Berkeley. On the second day, I joined several plenary and lightning talk with Taskcluster team member, coded together with the team for a few hours, then headed for dinner with the Voice and Inclusion Team. During the dinner I met my Female Mentor, Soledad from DevTools team and Josh Matthews, who is the maker of the well known BugsAhoy and currently is a Mozilla employee. On the third day, we (My mentors and I) had meeting with Josh Matthews, the BugsAhoy creator and Patrick from DevTools team to discuss about the history of BugsAhoy and how to improve the site to help more contributors find their first contributions. Then, I coded a bit and went for my team event in SF Conservatory of Flowers. On the next day, we went to a meeting with ParSys team, represented by Florian and Johann, coded a bit, and went to Taskcluster migration celebration. On Friday, I coded, biked with other intern and contributor, and went to the closing party of All Hands. So sad to say goodbyes!

Some questions raised during meetings:

1. How to guide someone after he/she had fixed a good-first-bug?
2. Should we focus on good-first-bug or mentored bugs as well? How to mark and differentiate them?
3. How to simplify the site (minimal click for everyone)? Should we have I’m feeling lucky button on all page?
4. Should we add a section for Featured / Popular projects?
5. Should we add a How-to-get-started for each project?
6. Should we add footer containing contact person of each project?
7. Should we also display assigned bugs?
8. Should we add specific tooltips for each bug, e.g for new unassigned bugs, say something like “Go for it”, for old unassigned bugs, say “Ask the mentors first to know if it is still a relevant bug to work with or pick other bugs”, etc
9. Should we display Diamond Bugs (bugs type that meant for bugs after good-first-bug) as well?
10. What type of bugs should be the default bug to be displayed?
11. Should we filter bugs based on mentor name as well (since some contributors might follow particular mentors’ bug after they know the mentor)
12. Does / will the Leader board help to increase contributor? How to filter it from Mozilla employees?
13. Should we have a bot on twitter to reward people after contributing?
14. Should we filter based on Project Technology as well, and how?
15. Is bug title enough to give description of the project?

Overall, it is really a wonderful and eye opening experience to attend All Hands. I would not be able to meet amazing people I used to meet online with, be taught tons of tips, and have long discussion with them had I did not go to All Hands.

Also, last week my PR regarding fetch from github API v4 has been merged! Now you can see issues gathered from github, e.g Test Automation’s issues (http://codetribute.netlify.com/projects/automation).

Left to right are YD (GSOC intern), Irene (Previous Outreachy Intern, now a contributor), and me! (I also have one team picture, but I’m not sure if I can post it here)

Fourth Week as Outreachy Intern: Query from GraphQL using React-Apollo

I’m back again guys!

Last week I have merged two PR, one for the search bar and another for the individual project page. I have also started designing the UI, adding color and icons. I am not so experienced in it but I hope I can finish it as soon as possible because I feel like the look of the site is an important aspect to make the site more trustworthy and appealing.
Now I am going to talk about possible ways to query using React Apollo 2.1 that I know of.

• Using ApolloConsumer‘s client:
  We can do something like this:

How to get the client from ApolloConsumer and pass it as props

Then later, we can use the client props in MyComponent to fetch data. Here is one of the examples of how to perform the query:

Graphql Query using client.query

It works as a JavaScript promise and we can add query, variables, context, and other networking options to it as well. I feel like it is a bit similar to how we usually fetch data from REST API.

• Using @graphql decorator:
  This is probably the most common one to be used.

  

  GraphQL query using @graphql decorator

  We can pass variables, context and a lot of other networking options to the options, but one thing that I think is lacking is passing props to the query itself, which in this case is the bugsQuery.

• Using <Query> Component:
  I think it is the newest feature provided by React Apollo, you can check on their documentation on how to switch from @graphql decorator to be using this Component. Their docs also cover some special use cases, like if the user previously uses compose then they can use nested Query component to perform similar operation, etc. In this Query Component, I can make the query to be a function that takes props as parameters and return the query based on the parameters.

  

  GraphQL query using Query Component

All in all, I feel like switching from one way to another will not be very hard as they all have similar arguments, however, I do need some time to read the documentation to adjust the options parameters as they can have different placement / type. I hope I can be a faster documentation reader as time passes by as it might save a lot of time if you can quickly know which part you need to read, navigate to the part that you need and understand it shortly after.

Another thing I discover is that even though GraphQL is designed to have one endpoint, you can actually combine two client to get your data from within one ApolloProvider. It is done by using split. Later on, when you want to fetch data using either of the approach above, you can select one of the client by using context which you can put in the options if you use @graphql, as attribute if you use  <Query> component, and as parameters if you use ApolloConsumer‘s client.

In my project, I use GitHub v4 API that utilize GraphQL and sometimes I wonder how they can limit user access based on the token we generated since we all use one endpoint to fetch the data. I will try to find sources about it later I guess.

I also managed to read a book about React called The Road To Learn React during the weekend. It was recommended by one question I read on Quora and since I love reading then why not. I will talk about it on later posts maybe, stay tuned!

Third Week as Outreachy Intern

Hello guys!

I can’t believe that two weeks of my Outreachy internship has passed, time flies real fast!

Last week, I start working on querying bug from Github API v4, while fixing bugs and making improvement in other open Pull Request.

Conflicting CSS Classnames on Production Build

One challenge I faced is conflicting CSS classnames on Material UI, which only happen on production build. It causes the display to be broken in the deploy preview, e.g: it appears as if Card is on top of Paper while in the class, I don’t declare any Paper. However, this issue does not seem to happen in my localhost.

First, I try to inspect the element. At first I could not find anything since all Mui- classnames are renamed to jss1, jss2, etc. Thus, I have to do my own mapping to map the class to my code. Then, when I inspect the styles, it seems like CSS classnames jss1 overrides each other.

I managed to solve the problem by:

1. Remove material-ui, @material-ui/icons, and @material-ui/core (it is because the @material-ui/icons are already referencing to @material-ui/core)
2. Add back @material-ui/icons and material-ui (the beta version)

Voila!! It works!! Yay!!

Github API v4

After that, I try to fetch data from the github API v4. Since some Mozilla project has more than one repositories, I want to find query format that can gather all bugs from several repositories. At first, I don’t think it is provided, thus, I use something like the below, with a little modification to add labels as parameter, a few more fields that I need, and ordering:

{
 a: repository(owner:"mozilla", name:"coversheet"){...OpenIssues }
 b: repository(owner:"mozilla", name:"memchaser"){ ...OpenIssues }
}
fragment OpenIssues on Repository{
 nameWithOwner
 issues(first: 100, states: [OPEN]){
  nodes{
   number
  }
 }
}

However, though it works fine, I feel like it is not very efficient, since we have to do a lot of processing, before and after the query.

Later on, my mentor, Eli, suggested me to try on using search query which I think I will end up using as it reduces the processing needed since we can specify all we want in a single string and pass it as parameter.

However, a little shortage is that the query string works like AND operation for labels. Thus, when we have different labels for different repositories, we still need to separate the query to find bugs which only satisfy one label (good-first-bug only instead of good-first-bug and mentored). I hope one day the Github GraphQL team can provide some way to do OR operation in the labels.

I also fix some styling, remove redundant classes and delete some redundancies based on the review from Hassan, my other mentor. I also try to play with the Bugzilla GraphQL gateway to find out the query I will need. Lastly, I had a video chat with Abigail from Mozilla Foundation, after getting introduced to her by Dustin, to talk about how the work I do can be integrated with other pieces in Mozilla. I made a few notes about the chat and discussed it with my mentors. I believe talking to more people gives me a different view of how this project should progress and I really appreciate her taking her valuable time to listen to me and giving her suggestions.