Week 9

What’s Next—.js for Team TON?

$ cd Next.js

$ git log --reverse

commit message Friday March 27:

I started to make some significant progress on The Next.js Handbook. I’m on my way to becoming a Next.js intermediate user! This process is necessary if our team plans to contribute an example Next.js project to the main repo (see week 08). In support of this goal, I also started looking at potential topics we could base an example project off of. It’s been a little tricky determining what technologies would be valuable to pair with Next.js. I’ve looked into incorporating a SQL Knex / Next.js technology fusion of some kind, but this idea needs a little more time to bake. Some things I will need to research before making a feature request for this kind of example include:

  • Does a Knex/Next.js technology pairing make sense?
    Is it relevant?

  • Are there any existing PRs, issues, discussions, of chats related to using Knex with Next.js in the project?
    Whose using it, if anyone? Are there issues with combining the techs?

  • Actually look into building a Knex/Next.js demo application.
    Is it within my team’s capability? If not, what extra resources are needed to get us there?

commit message Saturday March 28 ~1:00:

Way to go team TON!:rocket: So my awesome group took up some space on closed and merged PR’s today for the Next.js project!

@MichelleLucero went typo hunting in the Next.js project and spear-headed our need to jump on some changes we were discussing about for some time as a group. So we finally took action! @Liulanz had the most action on her PR with 5 comments! There may have been a few reforks and accidental commits to the canary (master-equivalent) branch involved, but we made it! This was our first set of contributions to Next.js project. While these contributions are small independently, they add an immeasurable amount towards our enthusiasm and prospects for the Next.js project. The feeling is surreal in the best way possible, and definitely makes us a little more comfortable about the contribution workflow to a real FOSS project on GitHub :grin:.

commit message Saturday March 28 ~6:00:

Tweaks for the Greater Good. :hammer_and_wrench: :art: Due to the accidental commits made to the canary branch on our fork (and the intricacies involved with navigating a single repo with four write-access priveleged members), it was time to get a little creative. In addition to coming together as a team on what workflows to avoid moving forward, I added a Branch Protection Rule to our fork.

:construction: Before making this rule I read up on protected branches and settled on requiring pull request reviews before merging to the canary branch. Hopefully, this prevents us from doing something potentially dangerous to the canary branch in the future :joy:.

Kevin Fleming :octocat::mega:

I found Fleming’s response to a peer’s question on how to approach Open Source contributions to be insightful and honest. He gave a comprehensive overview of his background in the FOSS world and offered some insight on common workflows and interactions to expect when approaching a FOSS community. My favorite tidbit from this response was his authenticity in encountering potential bugs and posing it to the community. He explained that it is common to post an issue or bug to a project and be redirected by core-maintainers or other community members familiar with the project to existing issues, PRs, or discussions about the bug. Community members may also disregard the issue as something specific to you, or take new actions to address your issue. While Fleming didn’t outright say his original bug may not have been valid, he certainly went into a few scenarios and procedures that would happen if the original issue proposed to the community wasn’t perfect. I found the familiarity in which Fleming spoke of being redirected by community members to be comforting. It’s nice to know that even someone with many years of experience in the FOSS world can make rookie mistakes like proposing issues that may already exist. Learning that the procedure was common in the FOSS world is encouraging :blush:.

They Might Never Tell You It’s Broken :bug:

The author brings up a few good points on why people don’t report bugs that I agree with. Honestly, it’s easier to assume that you as an individual missed something, or that the error is common and someone already knows about it. After reading the article, however, I feel more empowered to put my issues out there. If I’m wrong, then great, someone will be temporarily annoyed that I missed something minor in a documentation somewhere. But if I’m right, then I would have made a positive contribution to the community by bringing it to their attention. So really, it’s a win-win situation. No matter what the outcome, it can only be positive. Having made my first mini-contribution to the Next.js project, I already feel more comfortable about addressing a FOSS community.

Wikipedia in a Nutshell

I’ve found Wikipedia Talk discussions to be hard and cumbersome when proposing amendments to someone else’s work. So far, most comments on the Talk pages for the articles that I’ve edited had unresolved issues that were flagged years ago. So inactivity on a page (as far as contributors go) can make it hard to gauge community perspective on content edits. On another note, I’ve found the WikiMedia Commons pages to be really interesting, as far as content licenses go.

Contributions Made This Week:

In addition to the Next.js PR, I made a few wiki contributions to three different articles: Edible Water Bottle article, Sewing Machine article, and King Manor article. Some of my peers wanted some help setting up emoji-support for their blogs and naturally I couldn’t resist :blush::star2:! So I issued a few blog PR’s that involved setting that feature up for them! Can’t wait to check out their blog posts!

‘Til next time,

Shania

:mushroom:

Written before or on March 29, 2020