CC technical blog

Sunsetting api.creativecommons.org

2026-05-06T00:00:00Z

Creative Commons (CC) will terminate the api.creativecommons.org service on 2026 Nov 02. Please note, however, that hosting or software failure may render the service unavailable before that date.

Removal Rationale

The API depends on the legacy ccEngine, which was replaced by the current CC Legal Tools on 2023-09-27. It is no longer maintainable.
The infrastructure hosting the API is no longer supported.
The data provided changes infrequently enough that an API is a suboptimal solution.

Next Steps

Evaluate existing flat files to replace API:
- creativecommons.org/rdf/index.rdf
  - This ccREL file has existed for a long time, but has never been very visible. Its accuracy was significantly improved with the new CC Legal Tools App static site generation starting in 2023 September.
creativecommons/cc-legal-tools-data: config/cc-legal-tools.csv
- This file is new this year. Its generation in the CC Legal Tools App can be modified or a new file can be generated if additional data is needed, a different file format is needed, etc.
If you are using DSpace, see: Replace api.creativecommons.org DSpace/DSpace#11808.
Please use the following form to share concerns or request ongoing communication: Sunsetting api.creativecommons.org feedback.

2024-05-28: New CreativeCommons.org launched 2023 September
2011-08-31: Summary of current licensing tools
2011-01-13: CC REST API Updated for Public Domain Mark
2009-04-02: Enumeration descriptions in CC Web Services
2008-07-24: cc.license in alpha

Deprioritizing work programs

2026-03-11T00:00:00Z

Unfortunately, Creative Commons (CC) has no plans to participate in future work programs like Google Summer of Code (GSoC) or Outreachy.

The Technology team remains grateful to these invaluable programs and the many contributors, interns, and volunteers that they brought. Still, the contributions of our community far exceed our ability to document them. For a history of free/libre and open source work programs at CC, please see: Open Source Work Programs: History — Creative Commons Open Source.

Despite their ongoing success, the issues and problems that these work programs were created to address have only grown along with other changes in the technology industry. Their mission remains as important now, as ever. We hope their value will continue to be recognized.

For our part, we can only hope that the resources we developed for engaging with these work programs might benefit others and that someday we might be able to participate again.

Quantifying the Commons: The end of an era

2026-03-03T00:00:00Z

Quantifying the Commons: The end of an era

Dear gentle reader,

It is the end of an era yet the beginning of my bloom as a young aspiring data professional on a global stage. It feels so surreal to be at the end of this amazing journey with my mentors and to see the quantifying commons become a mature project in the creative commons open source community. Quantifying the commons is also blooming so stay tuned to experience its impact in different teams at Creative Commons.

Looking back, I was quite nervous on my first meeting with Timid Robot and Sara. I did not quite understand the automation part of the project, how long the scripts ran? Why? I was fascinated by the whole process of the system, after further explanation by Timid Robot I was really impressed by the design thinking. A lot of details and critical thinking were put into implementing the system. Big kudos to the project lead and previous contributors, I am in love with the foundation being put in place prior to my contribution. It is a firm one and it made my work easier and worthwhile.

Day 1 was amazing, Day 90 is growth!

I went from being confused with concepts used in the codebase to suggesting ideas on improving the automation process in the system. I constantly read articles, tested, iterated and improvised functions and mechanisms. I improved on my data structure and algorithm skills, I had to cater for test cases, limitations and risk. Risk in the sense that the system is exposed to change because the data is live and dynamic from the API. This is what I did in the first half of my internship here. I would be focusing on the second half of the internship in this blog post. A big part of the project is ensuring the integrity of data is in sync with the efficiency of the automation process.

Automating the Smithsonian quarterly report

Smithsonian is one of the largest public institutions in the United States. It has a total of 38 units/data sources like museums, zoos and libraries as of when I worked on it. We derived insights on the usage of CC0 license across the media records and records without media. This urged me to add the horizontal stacked barplot to the collection of visualization in the report system. From this, we could get the distribution of the records with CC0 licenses at a glance. Also, we explored the top 10 distribution of units and lowest 10 distribution of units. This meaningfully tells us how common the CC0 license is used in these institutions. After testing the whole workflow a couple of times, I detected that the unit code seems to be updated frequently whether added or removed. I developed a function that keeps track of these changes and gives a warning about changes in the next automation process. This was the best way possible at the moment to handle the sudden unit code, so that our data is quite predictable and updated.

Automating the arXiv quarterly report

Arxiv is a curated research-sharing platform with 5 million monthly active users and hosts 2.6 million research papers. We derived quite interesting insights from this data source. Then expanded the visualization collection in plot.py by adding the function for line plot and vertical stacked barplot. The insights include the count of legal tools on a yearly basis and various comparative analysis of the tools over the years. We also explored the breakdown of these tools usage in different categories.

Lessons learned

I learnt so much about creating a structure when solving a problem. It is quite easier to debug and it presents a detailed workflow for future contributors to understand what has been done previously. It literally boils down to how you name your variable or how you use it in a function. I also learnt the importance of asking why. Timid Robot encouraged me to always question assumptions and understand the reasoning behind decisions. This was the best thing to do because it made the whole internship fun and puzzling. Things became naturally logical and I could connect the dots quite easily.

What Next!

I hope to continue volunteering my time on the project going forward. I am also eager to explore other open-source projects involving research, big data, and automation, and to further align these skill sets with my background in actuarial science.

Goodbye for now

I really enjoyed working with my mentors, I will miss our little chit chats about the holidays, the weather and even vacation trips. I look forward to catching up again in the future.

Quantifying the Commons: My Journey so far with outreachy

2026-01-22T00:00:00Z

Hi there! My name is Oreoluwa, from Nigeria. I am an Outreachy intern at Creative Commons for the December 2025 cohort. My project involves improving and expanding Quantifying the commons. In this post, I will share my progress and key takeaways from the first half of my internship.

Project overview

Quantifying the commons aims to track and analyse the trends of the creative commons legal tools. Who is using these legal tools, where, why, how? We want to measure the impact of these tools. For the past 25 years, efforts have been made by the organisation to democratize knowledge and content on the internet. We want to identify our growth, gaps and areas for development.

A brief history I learnt about

After watching a documentary recommended by my mentor. I learnt about a great man called Aaron Schwartz who is also known as internet's own boy. He believed knowledge should be free and accessible to everyone. His ideas helped inspire movements like Creative Commons, which allows creators to share their work legally while choosing how others can use it. I resonate well with this movement because I realised how much knowledge I have gained from reading articles and my random searches on the internet. I feel really excited to be contributing to this mission.

Progress so far

Aligning the project better to the script requirements

One of the main script requirement is making the script repeatable

We use Github Actions to automate our python script on a quarterly basis. So there is an execution schedule that runs for 45 days or less. For better efficiency, scripts must exit early if a task is already completed and must reliably continue at the appropriate spot if multiple runs are required and not completed. Multiple runs in the sense that some of the APIs we integrate to fetch data have their limitations that allow a certain amount of fetch per hour or day. So we continue to fetch after the specified hour or day. During my work on the project, I implemented a mechanism that checks for completion of fetch scripts and allows the script to continue from when it stops during any interruption. I integrated a workflow that checks if an output has been generated previously to avoid regeneration or running of script continuously, when we have an output already.

Another script requirement is making the script idempotent

Making the script idempotent means executing the python scripts multiple times and still get the same output. Before my work on the project, the report scripts usually append it sections to the readme using the update_readme() function and this allows the order of outputs to change. For example when I run a script, I can get A-B-C but when I run it again maybe in the next quarter. I could get B-C-A, we don't want it like that. It should be predictable and consistent across quarters. But now,it inserts the sections alphabetically to the right position regardless of how the python scripts were executed. So we get A-B-C in quarter 1 and A-B-C in quarter 2.

Documentation on the project

Improving contributors experience is a big part of the project. During the Outreachy contribution phase, new contributors kept on asking the same questions over and over again because there were some lack of information in the documentation. Timid Robot and I tried to identify areas that were lacking clarity and we put in more context into the sides of the documentation.

Completing the three stages of report for existing scripts

Previous contributions had incomplete stages of report for a particular data source. I worked on completing the process and report stage for the Openverse data source. This required understanding the data fetched and what meaningful data or insight can be beneficial for the different teams in the organisation.

Current status

I am currently working on completing the process and report stage for other data sources. Then I expand the project by adding new data sources for reporting. An iterative task for me is to check for areas in the code that might need improvement or better ways of doing things in the codebase.

Collaboration with mentors

My favorite part of this project is my weekly meetup with my mentors, I get to ask questions, get ideas on ways I could improve something or solve a problem. I also get to review work done by my mentors, which allows me to learn from their approaches and imbibe them into my contributions.

Key takeways

Open source has been one of the coolest experiences in my tech journey. It has helped me expand my skill set, as I picked up new programming languages along the way. I learned to easily identify optimal solutions, especially when working within constraints or limitations that could affect outcomes. Through this, I realized the importance of building the simplest possible architecture first, and then gradually adding components as the solution evolves.

I am excited to embark on the next half! I hope to make more impact on this project.

Avoiding generative AI development tools

2025-12-01T00:00:00Z

At this time, the Creative Commons (CC) Technology team has concluded that generative AI development tooling does not pass a cost/benefit analysis for contributing to our open source projects. Until further notice, we will not accept CC Open Source submissions that include code or content generated with AI.

Overhyped

Generative AI productivity claims are often championed (and paid for) by those who reap a material benefit from adoption of AI tooling. Adoption rates are inflated by a lack of choice when AI tools are included by default and often cannot be disabled (EditorDavid, 2025). We’ve observed that arguments for their adoption too often appeal to a fear of missing out or potential future benefits.

Inefficiency and slop

Our current evaluation of generative AI development tooling is that it does not offer a benefit to our open source projects nor to the user of the AI tooling. Indeed, "when developers use AI tools, they take 19% longer than without—AI makes them slower." (METR, 2025). A recent report from MIT NANDA indicates "that 95% of organizations are getting zero return [from generative AI]." (Challapally et al., 2025). AI tooling enables the creation of spurious work for reviewers. For example, see the following comment on an AI slop submission:

This code does not call curl. This is not a "POC" of anything than [sic] suggesting you did this with an AI and that you do not understand what you're doing here.
Please identify the exact line of curl source code that has the problem you say exists.
(badger, 2025)

Counterproductive

Especially for our contributors, when we participate in work programs like Google Summer of Code (GSoC) or Outreachy, AI tools train the wrong skills. We want contributors who are learning the technologies that underpin our open source projects.

I listened to an industry representative say that he wants students to have “design thinking and the ability to ask questions” without recognizing that the student use of AI tools he advocates will stunt their critical thinking skills, making it impossible for them to ask questions and do interesting “design thinking.”.
(Valeries, 2025)

Responsibility and solidarity

In addition to concerns with how AI development tools might negatively impact our day-to-day, the Technology team has concerns about how generative AI technology is created and implemented/deployed. Even if generative AI development tools were actually helpful, the Technology team would be reluctant to use tools that were developed in a way that harmed others, that are funded by deployments/implementations that harm others, and that offer short-term benefits at an existential cost.

References

badger. (2025, September 16). Comment on Stack Buffer Overflow in cURL Cookie Parsing Leads to RCE. curl. https://hackerone.com/reports/3340109#activity-36894924
Challapally, A., Pease, C., Raskar, R., Chari, P., (2025, July). The GenAI Divide: STATE OF AI IN BUSINESS 2025. MIT NANDA. https://www.artificialintelligence-news.com/wp-content/uploads/2025/08/ai_report_2025.pdf
EditorDavid. (2025, May 31). GitHub Users Angry at the Prospect of AI-Written Issues From Copilot. Slashdot. https://developers.slashdot.org/story/25/06/01/0049240/github-users-angry-at-the-prospect-of-ai-written-issues-from-copilot
METR. (2025, July 10). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
Valeries, Barr. (2025, August 29). Feeling Cranky About AI and CS Education. Communications of the ACM. https://cacm.acm.org/blogcacm/feeling-cranky-about-ai-and-cs-education/

Refactoring and Releasing the new CC Chooser: Part 2

2025-10-06T00:00:00Z

This blog is part two of a three part series: Refactoring and Releasing the new CC Chooser.

The Creative Commons Chooser 2025 refactor offers a number of improvements across the surface of the application. Wherever possible we tried to consider if the footprint or implementation could be more straightforward and simple and then worked from there. The end goal being an application that would be considerably more flexible in its upkeep and advancement.

Reevaluating core features and use

This was accomplished by first understanding and reestablishing what the core set of functionality the Chooser should provide.

We started with the use cases that were present within the 2020 beta Chooser:

Provide a license recommendation
Passively educate the user about licenses and their properties/use-cases
Allow a user, who is an Author, to generate a "mark" in a variety of formats (which generally meets the requirements of the license)
Allow a user, who is a reUser/reMixer, to generate an "attribution" mark when not adequately provided from the original author

From the above four use cases, 1 & 2 were the original core aims of the Chooser.

Use case 3 was added as a mechanism to make applying the choice easier (but if the Author doesn't adequately provide a mark with Attribution Information then reUsers/reMixers may not be able to meet the spirit of the terms of the license (Attribution being required). The Attribution Details being optional is true in that it doesn't block a license recommendation, nor the passive education (1 & 2); but if a user is expecting 3 as a main use-case then the Attribution Details become required, colliding with a contextual expectation.

Use case 4 was not an intention of the Chooser, but something users have ended up using it regularly for, since Authors will often only use a general marking statement, such as “This Work is licensed CC-BY”.

Moving forward we would hope to focus on use cases 1-3, with the initial MVP scope of the Chooser refactor prioritizing 1, and then moving into the other two as supporting use cases. Use case 4 will not be a primarily supported use case, but we expect people will continue to use the Chooser for it until a better tool comes along.

Turning scope into technical methods

The Chooser spirals outward from the core decision pathways in the stepper guiding someone through a series of questions and resulting recommendations.Those pathways have two main branches that fork at the beginning (Do you need help? Yes/No), and regardless of what comes after, eventually provide an appropriate recommendation once all required fields are met.

From there, the Attribution Fields can be filled out and will populate the Marking section to allow for easier work marking from all the available user supplied data.

This means the decision stepper is the core piece of technical functionality that we would need to stabilize first, and everything else would then build from that standard setup.

We could employ a method of interwoven if/else and/or switch statements that moved through a series of logic gates checking against combinations of question/answer pairings combined together into certain recommendations, but in the case of the Chooser we already know what all the answers are. We know that the recommendation can be 1 of 7 possible legal tools, and that there are two main pathways to get to each of those tools from the “Do you know which license you need? yes/no” question.

If we work backwards from this premise we can standardize these pathways into a format which can describe the complete decision tree, and then work backwards.

That then looks generally like this:

[step-1-question]/[answer]/[step-2-question]/[answer]/…/&tool=[tool-req-name]

This breaks down into 14 possible correct pathways.

This format lets us describe the pathway state throughout a particular UX, in a uniform and easily parsable format.

From there we can set up the form to build out a state pathway as questions are answered, and when a full path matches a possible correct path end state, a particular recommendation can be accurately made.

Everything else can be assumed to be unknown (non matching).

This gives us a starting point to set up a simple state machine, and check against routinely at specific events and provide recommendations and/or update the interface.

Reducing the JavaScript footprint and overhead

Once we no longer needed a complex state management engine because we only have 14 possible correct “states” we’d like to handle, we could move away from the need for a larger more complex state management framework like Vue.js.

The 2020 beta Chooser utilized Vue.js and its dependency chain, the newer 2025 Chooser refactor utilizes a single vanilla JavaScript (JS) file. This resulted in approximately a 98% reduction in the amount of JavaScript!

This also lets us dramatically reduce the dependency chain, which in turn makes the Chooser more secure, more stable, and more maintainable overall.

Running the project through the SCC tool shows the newer refactor would be estimated to cost $113,716 to develop, take 6.02 months, and require 1.68 people to complete.

The refactor planning began in 2024, but the total time from initial refactor to completion code-wise was approximately 3 months (half the estimated time), with 1 person working on it part time (due to other obligations and responsibilities).

The original 2020 beta Chooser run through the SCC tool shows an estimated cost to develop of 8.88 months, and requiring 3.16 people to complete. This means not only did the refactor overperform on cost on its own estimations, it reimplemented the same degree of functionality with 1.8% of the code of the original, and accomplished what would have taken 3 people to do in 9 months full-time.

This is good, because the Chooser needs to be more maintainable and stable, but also flexible enough to build out newer features over time.

The state paths and smaller footprint means that we are left with a minimal amount of logic required to alter the visual state of the UX, and to allow a user to move through the stepper, the attribution fields, and the various marking formats and their individual functionalities.

Embrace native support and semantics

As the decision stepper is the main interaction element, the new markup was first built from there, setting up a semantic form, grouped into fieldsets, and labelled accordingly.

The classes in particular let the markup describe each component in a way that can be more directly tied to the logic the JS will later perform.

There is some measure of dynamic “data + markup” being swapped within the UX based on user selections. Previously Vue.js packages and their dependencies would handle holding onto this data.

In the refactor we opted to make use of the <template> element, which let us lean on existing HTML and JS functionality, and also established a foundation from which more robust Web Components could be utilized later if such a need arose, giving us a stable path of complexity to follow down the line.

We also opted to avoid the use of popup modals and tabs, and instead leaned on <summary>/<details> elements instead to accomplish similar behavior without the need for JS based behavior. Once again keeping our JS footprint much smaller.

Improving the UX

Reducing friction

We tried to reduce redundancy and better control friction within the UX wherever possible in the 2025 refactor.

The prior 2020 beta Chooser had “Next” and “Back” buttons within the interface which largely had no necessary purpose. The Tool Recommendation was often updated live as fields were filled out, so the only reason to hit the Next button was to get more of the input interface to appear, rather than to get more useful output within the Recommendation area.

With the refactor we removed these buttons, giving the user the ability to move from fieldset to fieldset within the UX without an additional step in the process of input. Whether they move forwards or backwards the UX responds accordingly without the added friction. This lets people move through to a recommendation much more quickly. This change also lets us remove the “Reset” button as well, since moving backwards through the fieldsets will reset lower fieldset values automatically. We also get a boost in accessibility with its removal, since it’s not advised as a solid use case within accessible interfaces, due to it being too easily clicked.

“The Web would be a happier place if virtually all Reset buttons were removed. This button almost never helps users, but often hurts them.” (Reset and Cancel Buttons - NN/G)

We also removed the final "Done" button and its adjacent shaking behavior. The “Done” button had an erroneous purpose, since the recommendation was already available on the right, and it was unclear why the “Done” button would be necessary to reach a final UX state.

The shaking behavior is also generally a UX convention deployed to indicate that an error has occurred or that inadequate or incorrect information has been input within a form. The original aim with the prior chooser was to draw attention to the Tool Rec and marking areas being “finished”, but instead communicated that some form of error had occurred. This was reported multiple times by users, so this behavior was removed entirely to make things less confusing and more clear.

The shaking behavior was accompanied by a form of “scroll jacking” which would scroll the user’s viewport back to the top so the shaking behavior could be visible when it occurred. This was also removed.

Overall, we also tried to remove the number of steps, clicks, or choices a user might have to move through to get to a usable recommendation where possible. One clear example of this is prepopulating the first question with the default of “Yes”. This means returning users who are already familiar with the choice can proceed more swiftly without adding any additional steps for those that still need help.

Attribution marking now shows up as soon as a tool recommendation has been provided, linking the two together better contextually, and not as a later phase of the form’s state lifecycle.

Adding friction

To make the UX more usable we also added friction where it made sense. The pathway that leads to a CC0 recommendation no longer provides a recommendation without checking the two acknowledgement checkboxes, to ensure the user is given the chance to fully understand what they are doing by utilizing CC0.

We also leaned more on the “Need Help?” section to provide deeper explanations rather than adding more information in other areas. This section’s newer placement lets it serve as a way to drill down further, without having to increase the density of information in the fieldsets.

Despite being a rather simple interface the Chooser offers several overlapping use cases, and as such we tried to find subtle ways to bind distinct areas of input to related areas of output either with attention focus, or with some measure of connective mechanisms.

The Attribution fields include descriptive placeholder data, which also shows up within the various marking formats helping to bind the two areas together as having an input/output relationship not just generally, but also more specifically for the individual input fields and output tokens. This allows a user to start with the Attribution fields and see the results in the Marking formats, or first encounter the Marking Formats after reaching a Tool Recommendation, and then make a connection back to the Attribution Fields as the input source for them. The goal being a bi-directional relationship that is intuitive.

Another area where this shows up is with the Tool Recommendation itself. When it appears after a successful set of fieldsets align it is distinctive in its appearance, but it also has a “waiting for required fields” placeholder element for the zero state of the UX, so that the shift is more intuitive that results will appear here once input, and that they are also distinct visually from the Marking Formats section below.

Increasing plasticity

The final result of the refactor is a dramatically smaller and more manageable codebase, a much narrower pathway of function and logic, better integration with the Vocabulary Design system, and a robust use of semantic accessible markup. This radical reduction in the code footprint and complexity overall means the refactored 2025 Chooser is now much more agile and can more easily grow or pivot in new directions.

Closing

Overall, the code footprint is now 57.52 times smaller! If the refactored codebase's footprint was Earth, then the old codebase's footprint would be Neptune, since Neptune's volume is 58 times larger than Earth (you can fit 58 Earths within Neptune)

Despite the number of improvements throughout the refactor, one of the key goals was clearing out enough bitrot and complexity to make room for the project to grow sensibly and responsibly again. We weren’t just trying to improve the Chooser for a static launch, but to reposition it so that it could once again grow more easily in the directions that would benefit its users most.

We already have a bit of a roadmap in mind, and we’ll get into that in the final installment, Part 3: Future Growth: What’s next for the Chooser, and what directions we hope to grow it.

Refactoring and Releasing the new CC Chooser: Part 1

2025-07-11T00:00:00Z

This blog is part one of a three part series: Refactoring and Releasing the new CC Chooser.

We’re excited to announce that we have finally moved the Chooser from a long-term beta state into a finished and stable v1.0. But it certainly hasn’t been a straight-line. The Chooser has been met with a lot of challenges along the way and in this series we’ll walk through that journey in three parts:

Part 1: History and debt: The historical context that led to the newest refactor and release of the 2025 Chooser.
Part 2: Specifics and fixes: Breaking down the specifics of technical debt, issues, complexity, contextual-shift misalignment, and fixes.
Part 3: Future Growth: What’s next for the Chooser, and what directions we hope to grow it.

What’s the Chooser?

From our website:

Our chooser helps you determine which Creative Commons License is right for you in a few easy steps. If you are new to Creative Commons, you may also want to read licensing considerations before you get started with the chooser

Circumstances and context

What do you do when an ecosystem shifts, not just with the number of engineers, but also from the focal point of complexity built around a core product that no longer exists at an org? You evaluate the context within which everything exists and you reevaluate what works from there forward.

The Chooser has existed as a tool within the Creative Commons (CC) main website for over fifteen years, and helped guide countless people through their choice of sharing restraints and freedoms combined with which Legal Tool those requirements are best aligned with. In 2019 the Chooser was met with a need to refactor both its UX, and also its core technological approach. The CC Technology team was focused hard on CC Search, which would later launch in the Summer of 2019. CC Search was a rather complex application that required a more robust and dynamic user interface. It was in every way much more of an app than a website and so the team chose to build out the CC Search engine with Vue.js. Like the rest of the JavaScript ecosystem, this meant some speed and affordances in dev time with a trade off in larger code dependency and complexity; given the size of their team and the ecosystem they were seeking to build it was a solid and reasonable judgement call.

Building an ecosystem from a strong core product

After landing on Vue and setting to work to build out the search engine, it became reasonable to also move as many other projects to the same ecosystem so that updates overall could better operate as a supportive ecosystem. If other websites and projects were moved to Vue, then they could share dependencies, benefit from fixes and updates, and as the CC Search engine grew it could have the delightful benefit of lifting up all the other projects along the way.

With a larger engineering team to manage the ecosystem it made a lot of sense (Node is sprawling, and can be overkill in the wrong circumstances). It decreased the complexity of managing a search engine, while adding some complexity to smaller projects, with the balanced gain of spreading updates and works across the whole a lot more cohesively. The end goal here was a development environment that was much less siloed and more responsibility consistent in how it approached dev work.

Vocabulary also entered the picture at this time. Its goal was to operate as a design spec and implementation “rule system” for the Vue framework implementation.

Shifting circumstances

In 2020, Covid shocked our society, disrupted giving, and brought staff reductions to Creative Commons. Most of the Technology team was laid off. Work was mostly suspended, some projects were sunset, and others were left with minimal maintenance. Thankfully, CC Search was acquired and continued by Automattic as [Openverse][openverse]. However, with its absence came a rather large hole at the center of a very large development wheel.

Without the CC Search engine, now all the smaller projects which had adopted Vue would no longer receive the benefit of being attached to the larger project’s progress. Instead a balkanization began to unfold. The flexibility and scale that the Node ecosystem had offered when the CC Engine existed at the organization no longer applied, and now Node in all its forms within all the various projects were a liability instead of a strength.

Node is a fast moving system, and without a larger team it was difficult to keep dependencies updated, tested, and secure. Projects began to drift away from each other. Some projects still utilized Vue, others only halfway, and others abandoned in-progress migrations to Vue, instead falling back to what they had been doing before. The ecosystem fragmented and technical debt began to accrue. Since Vue (and by proxy Node/NPM) moves so quickly–the debt accrual was considerable.

The 2020 Chooser in limbo

The 2020 Chooser, left with minimal maintenance, was a beta version. It was revamped and rebuilt to focus on the latest legal tools, offer a better UX, and incorporate the Vocabulary design system. It was built from the ground up entirely within Vue. And so the Chooser largely stayed, mired in beta due to an ever increasing amount of technical debt. The rest of the world was moving from Vue 2 to Vue 3, but there wasn't capacity at CC to update the Chooser.

By 2023, the Technology team had the capacity to begin reducing technical debt. Later that year the main CC site redesign was launched. That work cleared the way for redoing the Vocabulary design system, removing Vue, and simplifying its approach to be better scaled to a more concise set of engineering resources. The new site better utilized native WordPress functionality and minimized JavaScript (it did not use Vue or any other JavaScript framework).

Laying groundwork for a refactor and release

A lot of time had passed since its original beta redesign and 2020 beta release. The scope of the Chooser needed to be reconsidered. The core of its functionality needed to be narrowed back down to manageable goals, decision pathways, and stable long-term engineering.

In 2025, the Chooser was updated to better align with both the larger CC dev ecosystem and the capacity of the Technology team. These changes have resulted in a Chooser that is more integrated, balanced, stable, and viable long term.

Moving forward

In the next part of this series we’ll walk through the technical debt the Chooser had accrued, and the specific improvements and changes that we’ve implemented!

Migrating from MariaDB 10.4 to 10.11 on AWS RDS

2025-03-24T00:00:00Z

As part of AWS’s request to migrate the RDS DB engine from MariaDB 10.4 to 10.11, this blog post provides a detailed, step-by-step guide to ensure a smooth transition. We’ll cover the pre-migration steps, the actual upgrade process, and post-migration verification to minimize downtime and potential issues.

Let’s dive in!

Pre-Migration Steps

Before performing the upgrade, it’s essential to ensure a structured migration plan, especially if your environment has customized database parameters. Follow these preliminary steps:

Create a DB Parameter Group – Customizes database-specific settings for the new engine version.
Create an Option Group – Manages additional features like replication and logging.
Backup and Test – Take a snapshot of the existing database to prevent data loss.

Create a DB Parameter Group

RDS DB Parameter Groups allow you to configure database-specific parameters, such as memory, cache, and other DB settings. You need to create a custom DB Parameter Group for MariaDB 10.11 because different versions require different settings.

How to Create a DB Parameter Group

Login to AWS Management Console
- Go to the RDS service in the AWS Management Console.
Navigate to Parameter Groups
- In the left navigation pane, under Databases, select Parameter Groups.
Create a New Parameter Group
- Click on Create parameter group.
- Parameter group family: Choose mariadb10.11 from the dropdown.
- Group name: Provide a meaningful name like webserver-stage-rds parameters-mariadb-10-11.
- Description: Optionally add a description such as "Custom Parameter Group for MariaDB 10.11."
- Click Create.
Modify the Parameters
- Once the parameter group is created, click on it to edit.
- Modify the parameters as per your application’s requirements, e.g., change innodb_buffer_pool_size,time_zone, etc., to optimize for the new version.
- Click Save changes once done.

Create an Option Group

Option Groups are a collection of database options (such as replication, backups, and logging) that you can apply to RDS instances. To migrate from 10.4 to 10.11, you need to create and associate an Option Group with the new engine version.

How to Create an Option Group

Go to Option Groups in RDS
- In the AWS Management Console, go to RDS and then Option Groups under the Databases section.
Create an Option Group
- Click Create group.
- Option group name: Provide a name like default:mariadb-10-11.
- Engine version: Select MariaDB 10.11.
- Click Create.
Add Options to the Group
- Select the new Option Group you just created.
- Click Add option to save the selected options.

Perform the MariaDB Version Upgrade

Once you’ve created the required DB Parameter Group and Option Group, you’re ready to perform the migration from MariaDB 10.4 to 10.11.

How to Perform the Migration

Backup Your Database
- It’s important to create a snapshot of your current DB instance before starting the upgrade process. This ensures that you can roll back in case of any issues.
- Go to your RDS instance and click on Actions → Take Snapshot.
Modify the DB Instance to Use the New Version
- Navigate to Databases in the AWS RDS dashboard.
- Select the DB instance you want to upgrade.
- Click Modify at the top right.
- Under DB Engine Version, choose 10.11 from the drop-down.
- Under DB Parameter Group, select the custom parameter group created for 10.11.
- Under Option Group, select the newly created Option Group for MariaDB 10.11.
- Click Continue.
Apply Changes
- Choose whether you want the changes to apply immediately or during the next maintenance window. For minimal downtime, apply during the maintenance window.
- Review the changes and click Modify DB Instance.
Reboot the Instance (if necessary)
- Once the modification is complete, your DB instance might need to be rebooted for the changes to take effect. Confirm and reboot if prompted.

Verify the Migration

After the upgrade is complete, it’s time to verify the migration.

Check DB Engine Version
Check Application Performance
- Test your application to ensure that it works properly with the new MariaDB version.
Review Logs
- Check the RDS logs to verify that no errors have occurred during the upgrade process.

Post-Migration Clean-Up

Delete Old Parameter and Option Groups (if not required)
- Once the migration is successful and tested, you can clean up unused Parameter and Option Groups to avoid unnecessary overhead.
Monitor and Scale
- Monitor the instance for any potential issues and scale the resources (e.g., CPU, memory) if required based on the performance of MariaDB 10.11.

Conclusion

Migrating from MariaDB 10.4 to 10.11 on AWS RDS is a straightforward process, but it requires careful planning, especially around DB Parameter Groups and Option Groups. By following the steps outlined in this blog post, you can ensure a smooth transition to the latest MariaDB version, improving the performance, security, and scalability of your application. Remember to always perform proper backups, test the migration in a staging environment, and monitor post-migration performance to ensure everything is functioning as expected.

Best Practices

✔ Always test the migration in a staging environment before applying changes in production.
✔ Monitor RDS logs and application performance after the upgrade.
✔ Ensure proper backups before initiating any engine version changes.

By implementing these best practices, you can enhance performance, security, and scalability while ensuring a successful migration.

🚀 Happy migrating!

References

Reflecting On My Outreachy Journey With Creative Commons

2025-02-27T00:00:00Z

It feels like just yesterday I was writing my first blog post, trying to wrap my head around all the things I’d be doing during this internship. And now, here I am, writing my final post—time really does fly when you’re deep in code, refactoring, and figuring things out.

When I started, I was both excited and nervous. I knew I’d be working on implementing and consolidating the Vocabulary design system across different Creative Commons ancillary websites, but I didn’t fully grasp just how much I’d learn along the way. The idea of making a meaningful contribution to such an impactful organization was thrilling, yet there was that little voice in my head wondering: Can I really do this?

Spoiler alert: Yes, I could—and I did!

From Day One to Now: The Journey

My first few weeks were all about getting familiar with the codebase, understanding how Vocabulary worked, and figuring out how the different websites used it. I remember spending quite a bit of time just reading through the Vocabulary documentation, going through all of the websites to identify discrepancies, and trying to piece things together.

Looking back, it’s funny how something that once felt so complex now feels like second nature.

Refactoring the Issue Finder: Removing Vue for a Simpler Setup

One of my major tasks was refactoring the issue finder tool on the Creative Commons Open Source website. This tool was built using Vue.js, but the goal was to remove Vue and refactor the JavaScript to align with the vocabulary approach - using HTML and CSS as much as possible with minimal and plain JavaScript.

At first, this felt like a huge task, especially since I hadn’t used Vue before. The Vue-based setup handled filtering, UI interactions, and data fetching. Without a framework, I had to ensure that the core functionality remained intact while simplifying the code.

I started by carefully analyzing how Vue was being used in the project. Then, I broke down the refactor into smaller steps:

Removing Vue dependencies and setting up a plan to replace its functionality with vanilla JavaScript.
Refactoring the JavaScript—rewriting event listeners, handling state manually, and simplifying functions where possible.
Ensuring everything still worked-since Vue had handled reactivity, I had to make sure UI changes (like filtering issues) were updated correctly without unnecessary complexity.
Testing and fine-tuning—checking for edge cases and making sure the refactored version behaved just like the Vue version (but with cleaner, more maintainable code).

Working with DataTables: A Whole New Learning Curve

One of the most interesting things I learned during my internship was working with datatables Before this project, I had never even heard of DataTables. I spent time reading through the documentation, testing out different configurations, and experimenting with how it handled datasets.

Initially, I added DataTables to the project using a content delivery network (CDN), which was the quickest way to integrate it. However, after a suggestion from my mentor, we decided it would be better to download the source code and add it as a vendor folder in the project.

After setting it up, I worked on overriding some default styles to make sure datatables aligned with Vocabulary’s design system. I had to carefully adjust CSS properties, inspect the DOM structure, and test different solutions to make sure everything looked cohesive.

This entire process taught me an important lesson:

Documentation is your best friend. When dealing with a new tool, reading the official documentation can save so much time.

From Midterm to Now: Wrapping Up and Final Contributions

After the midterm blog, my focus shifted towards finishing up the restyling process and addressing minor bugs across the Creative Commons Open Source website. These were smaller but important refinements—ensuring consistency, fixing UI inconsistencies, and making sure everything aligned with the Vocabulary design system.

Improving the Search Portal

One of the websites I worked on was the Search Portal. This involved:

Defining the CC abbreviation in the header section to improve clarity and accessibility.
Restyling the search input to align visually with the provided context in Vocabulary, making it feel more integrated with the overall design.
Making downstream changes to ensure everything was up to date with Vocabulary’s latest standards.

The goal was to keep the existing functionality and improve on the design, making sure the search input visually aligned with the design system.

CC Legal Database(LegalDB): Planning for Future Work

Although LegalDB was initially part of the project scope, time constraints didn’t allow for implementation. Instead, I'm focusing on laying the groundwork for future contributions by:

Identifying necessary changes and documenting them thoroughly.
Creating all the relevant issues and linking them to the larger tracking issue on Vocabulary, ensuring that future contributors have a clear roadmap to follow.

This is so that even though I couldn’t complete the work myself, the transition for the next person picking it up would be smooth and well-documented.

What’s Next?

This internship has solidified my love for front-end development, especially when it comes to building interfaces that are both beautiful and functional. My next goal? To dive deeper into animations, interactivity, and making the web more immersive (looking at you, GSAP and Three.js!).

I also want to keep contributing to open source and continue growing as a developer. This isn’t the end—it’s just the beginning of the next chapter.

A Heartfelt Goodbye (For Now!)

To my mentors, and everyone who supported me during this internship— thank you! Your guidance, patience, and encouragement made this experience truly special.

To future Outreachy interns: If you ever feel overwhelmed, know that it’s part of the journey. Keep asking questions, keep pushing through challenges, and most importantly—enjoy the process. You’ll come out on the other side with skills, confidence, and a whole new appreciation for open source.

And with that, it’s time to say goodbye to this chapter.

Until then, happy coding! 🚀

Finding Problems, and Exercising Compassion

2025-02-04T00:00:00Z

In engineering, in programming, in coding–in building anything that intersects with a human and a computer, context matters. It controls how a variable is scoped, how a function is called, and how styles in a CSS file might cascade and apply.

Context matters

As the saying goes, "Context is everything". But despite that, it can be easy to miss or ignore context, to skim past it when encountering issues, when hunting for problems.

So much of the engineering world is building things, moving things, refactoring things. It's a lot of activities that look and behave a lot like creating, but in equal measure a vast majority of roles and jobs in the field are about finding problems, whether by intention or accident.

It's why we have "Issues" in code repositories, the name alone signifies that something is amiss. An expectation was not met, a small part of this does not easily align with that.

Pause for compassion

Finding problems is as much the momentum of engineering as anything else, and once encountered, the problem begs for the next part; finding a solution.

It is here at this transition, at the border, that I would invite you to pause. To step back and reconsider the problem you've just witnessed, the thing that is amiss and possibly blocking the work you are doing in some way.

For it is here in this space, between problem-encountered, and solution-sought that we all could do better at exercising a degree of compassion.

This problem was, in many ways, born out of the context within which it was first introduced. It may have been the after effect of an unrealistic timeline, or an unintended consequence of decisions made well outside the control and influence of the engineer that introduced it. It may have been put there, with full knowledge of its existence, but without any ability to circumvent its inclusion.

The problem in question is not necessarily the product of one person, one team, or one process. It is, as is usually the case, the outcome of an interconnected and complex system of people and technology interacting and influencing one another.

It can be easy to lean into the gravity of assuming this problem was easy to avoid, that it is a sign of poor decision making, or outright malice. That it is specifically indicative of someone or someones' shortcomings in the field. But engineering as a space of people is a place that can at times be a list of limited options, and the correct choice is not the one with zero problems, but the one that is accomplishable with the least problems, or even the least negatively impactful problems.

Moreover, despite rigorous reviews and tests, things get missed, circumstances change, and given enough time the complex system we all work within has fault lines. Problems arise that no-one expected or anticipated.

Without context assume the best

Context is key, but it is also often a mystery. In the case of an inherited system, you may be left with the problems, but little if any evidence of the context in which they were generated. You are left with the duty to seek solutions, and little reason as to why the problems were introduced in the first place.

In all of these moments, we would all do better to remember compassion, to try to embrace that we do not know the full picture, the entire context. And that perhaps those before us, and around us did the best they were capable of within the system they were a part of.

It is certainly easy to jump to conclusions, lay blame, and cast judgements at the engineers, coders, tinkerers, and builders that came before us. "Why would they do it like this?" "This is a mess!" "I don't understand what this is doing here?" It's fair to be frustrated, and reasonable to question the "why", but a bit of compassion goes a long way towards building a community of trust and well being within the larger system of building things on and around the internet.

Safe to learn and safe to improve

Without compassion in these cases, we can foster an environment where people are afraid to make any mistakes. One major issue with this is that beginners, being beginners, make a lot of reasonable mistakes, and if they do not feel safe to make those mistakes then the arena of open source loses beginners, and without that it does not flourish, it does not thrive.

People, and the technological systems we create are imperfect. And the way we keep improving those systems isn't by solving coding problems alone, especially if those solutions don't come with a degree of compassion.

So, consider for a moment the next time you encounter a problem, pause for a moment and try to have some compassion, to put yourself in the place of the coder who came before, and then move on to seeking solutions with a degree of understanding across time that while we may not meet each other or share the same context; perhaps both of us were trying to make things a little bit better in what we did, and in the end we did our best to keep the system improving, code moving, and trust growing.

Outreachy Midpoint Progress With Creative Commons

2025-01-19T00:00:00Z

Outreachy Midpoint Blog Post

Hi there! My name is Queen, and I’m an Outreachy intern at Creative Commons. My project involves consolidating and implementing the Vocabulary design system across Creative Commons ancillary websites. In this post, I’ll share my progress and key takeaways from the first half of my internship.

Project Overview

The goal of my project is to implement the Vocabulary design system across several Creative Commons ancillary websites like the CC Open Source, CC Legal Database, CC Search Portal, and CC Resource Archive.

Progress So Far

Phase One: Refactoring Markup to Align with Vocabulary

In the first phase, I focused on refactoring the markup to align with Vocabulary’s components and context. Here are the pull requests (PRs) merged during this phase:

PR 118: Refactored the recent blog post section on the homepage.
PR 856: Refactored the homepage markup to align with Vocabulary components.
PR 862: Updated page-with-toc.html, which serves as a template for many pages.
PR 863: Initially, I planned to refactor the markup to Vocabulary’s context, but after feedback from my mentor, I instead removed legacy class names while retaining the table structure.
PR 865: Refactored the blog’s author page to match Vocabulary’s “person” context.
PR 866: Updated the blog structure to follow Vocabulary markup.
PR 867: Refactored the Project List page, leaving the table markup intact but removing old styles.
PR 868: Refactored the Issue Finder tool, replacing Vue.js with plain JavaScript. Although removing Webpack will happen later, this PR set the stage for future improvements.
PR 870: Aligned the Authors page with Vocabulary’s team styling.
PR 871: Refactored the Project Ideas page, incorporating Vocabulary’s project markup and removing legacy styles.
PR 873: Dynamically updated the body tag’s class in layout.html and added a body-class field to the blog.ini model file for consistent styling.
PR 880: Refactored page-with-title.html (used by CC Tech Archives) to align with Vocabulary.
PR 886: Updated the header component markup and removed old class names.

Phase 2: Adding Local Styles

After refactoring the markup, I moved on to styling sections that Vocabulary doesn’t cover. Here are some of the merged PRs so far;

PR 888: Added local styles based on Creative Commons’ main website for the homepage and other sections, such as “Get Involved” and “Featured Projects.”
PR 891: Created a new issue-finder.css file to restyle the Issue Finder page while removing legacy styles but maintaining legacy design.
PR 898: Integrated Datatables and jQuery by adding them to a vendor folder. Styled the table and code blocks using existing website styles.
PR 990: Styled the CC Search archive table using Datatables.

Current Status

I’m a little behind schedule—I had planned to start work on the Legal Database website by now. However, I’m wrapping up the CC Open Source website this week and will move on to the next phase soon.

Lessons Learned

This internship has been an incredible learning journey. Here are some key takeaways:

Technical Skills:

I’ve become comfortable working with Lektor, a static site generator that was entirely new to me.
Implementing the Vocabulary design system has improved my problem-solving skills, especially when dealing with legacy code and adapting the system to fit unique website needs.
To localize the table component, I had to read the DataTables documentation, which helped my ability to learn on the go.

Collaboration:

Working with mentors has taught me the value of clear communication, especially when addressing blockers or seeking feedback.

Project Management:

Breaking tasks into smaller chunks, prioritizing effectively, and maintaining consistent progress have been critical in managing this project.

This experience has significantly boosted my confidence as a front-end developer, particularly in creating user-friendly and accessible interfaces.

That’s it for now! Thank you for reading about my progress. I’m excited to see how the second half of this journey unfolds!

Skipping Google Summer of Code (GSoC) 2025

2025-01-15T00:00:00Z

The Creative Commons (CC) technology team regrets to announce we will not be participating in Google Summer of Code (GSoC) 2025. While the program remains excellent, we do not have the resources to participate this year and meet our core responsibilities.

We are grateful to Google for the program and have found incredible value in participating in past years. We look forward to participating in future years. We are thankful for the work and time of contributors. This is not an exciting announcement, but we will be better equipped to engage with work programs in the future.

Preparing to re-engage

In addition to revamping our CC Open Source website during the first quarter of this year, we will also be refreshing our structured community involvement, and improving our project lead resources.

Our CC Open Source website is in the process of being updated to be less technologically complex and to leverage the current Vocabulary design system (creativecommons/vocabulary).

Our structured community involvement has languished since the technology team was downsized due to the COVID pandemic (202-12-07 Upcoming Changes to the CC Open Source Community — Creative Commons Open Source). We will be simplifying community involvement so that we can be more responsive with increased visibility.

The most resource intensive period of a work program is the application phase. During this time there is a deluge of activity that has often exceeded our capacity. Developing our project lead resources will allow us to better set expectations, ease communications, and better point applicants on productive trajectories.

Past participation

For information on the excellent work completed during past participations, please see: Open Source Work Programs: History — Creative Commons Open Source.

My Outreachy Internship With Creative Commons

2024-12-10T00:00:00Z

Introduction

Hi, everyone! My name is Queen, and I’m a fresh pharmacy graduate with a passion for tech. My journey into coding started four years ago when I wrote my first HTML code and thought, "Yes, I’m FAANG-ready!" Spoiler: I wasn’t — but that didn’t stop me from dreaming big. Balancing pharmacy school and learning to code often felt like I was biting off more than I could chew, but I’m proud that I never gave up on my dream of becoming a front-end developer.

My Core Values

When I think about my core values, three words come to mind: Growth, Curiosity, and Knowledge.

Growth: I strive to improve in every aspect of life—mentally, physically, intellectually, and even spiritually. Every setback is just a stepping stone for me.
Curiosity: This one’s a work in progress, but I’m learning to ask questions and embrace not knowing. I love understanding why things work the way they do.
Knowledge: I read a lot because I genuinely enjoy learning new things. For me, knowledge is the key to confidence and growth.

My Journey to Outreachy

Outreachy is a three-month paid open-source internship program for underrepresented people in tech. I first heard about it last year—just two days before the application deadline. I didn’t make it past the initial application stage that time.

When the December 2024 cohort initial application opened, it was the perfect timing for me. By then, I had finished my pharmacy degree and was ready to gain professional experience in front-end development and most especially, in open source. This time, I was determined to get it right.

I applied on the same day the application opened, I had already kept answers for the essay questions in my notes app. While waiting for the results, I brushed up on my skills and read articles from past interns to prepare for the contribution period.

When I received the email saying my initial application had been approved, I felt a rush of excitement. To move forward and be able to make a final application, I needed to make at least one contribution to a project. I narrowed my choices to two based on the skills required, but Creative Commons stood out to me. Their mission and the project description piqued my interest more.

The Contribution Period

The contribution period was competitive—and intimidating. Seeing the amazing work other applicants were doing made me doubt myself. But I loved the project and found the community so welcoming that I couldn’t give up.

The mentors were incredibly supportive, giving feedback that helped me improve with each contribution. When it was time to draft my final application and proposal, I worked with my mentor, sharing my plans and got her input which helped me in creating my project timeline.

Even before I knew if I’d be selected, I felt fulfilled. Contributing to Creative Commons was a rewarding experience, and I knew I wanted to continue contributing to the community, intern or not.

My Internship Project

Consolidating and Implementing the Vocabulary Design System

During my internship, I’ll be working on consolidating and implementing the Vocabulary design system across Creative Commons' ancillary websites.

Vocabulary is a design system that ensures a consistent user interface (UI) and user experience (UX) across all Creative Commons websites. However, its implementation has been inconsistent, with variations in features and versions across different sites. My role is to identify these inconsistencies and work on a unified implementation that also focuses on accessibilty. I'd also be implementing features that might be a good addition to the design system.

I’m excited about this project because it aligns with my passion for front-end development and allows me to contribute meaningfully to a global community. I also get to improve my skills and gain new ones.

Conclusion

This internship is more than just a milestone for me—it’s a testament to perseverance and growth. I’m thrilled to embark on this journey with Creative Commons, and I can’t wait to see where it leads.

If you’re considering applying for Outreachy, my advice is simple: believe in yourself, stay curious, and never stop learning. Your journey might just surprise you.

Thank you for reading!

Local Environment Creation using Ansible and Docker: Part 2

2024-08-23T00:00:00Z

Midterm Recap

I successfully created customized Dockerfiles and a docker-compose.yml for web, database, and ansible for the past 6 weeks. However, to better replicate our production environment, which uses an AWS RDS instance, we decided to remove the customized Dockerfile for database, as SSH access is not required for the database host in this setup.

Week-by-Week Progress

Following our initial architecture design, I began working on building a bastion server. One of the key lessons I learned during this process was the value of simplicity. For instance, I had to assess the trade-offs between creating a custom Dockerfile and using a prebuilt image maintained by the community. In the world of DevOps, some terms are often loosely defined. For example, during my research on bastion servers, I encountered various use cases such as integrating MFA, logging, and other security features. However, these were beyond the scope of our current project.

For this project, we are building a bastion server primarily to serve as a secure gateway for managing access to internal servers. This specific requirement dictated a more straightforward implementation. In this context, I also came across the concept of "YAGNI" (You Aren’t Gonna Need It), which reminds us to avoid adding unnecessary features until they are actually required. Along the way, while working with Creative Commons (CC), I learned an important lesson: with so many tools, software, and technologies available, it’s crucial to focus on implementing configurations and solutions that are tailored specifically to our environment and requirements.

Before setting up the bastion server, it's also very important to understand the different SSH configuration options and choose the one that best meets our security and convenience needs. For instance, passwordless SSH enhances security and convenience by enabling SSH key-based authentication, but it requires public key configuration on each server, which can be cumbersome in larger environments. SSH Agent, on the other hand, improves the security and management of private keys by keeping them in memory across multiple connections. However, it requires running the SSH Agent locally and loading keys, adding some complexity to the setup. We ultimately decided to use ProxyJump because it offers centralized control and simplifies multi-hop connections through a bastion server, which provides strong security and convenience. While ProxyJump requires moderate configuration of both the bastion and target servers, it excels in supporting multi-hop connections and ensuring secure access to internal servers.

We finalized these details in the Bastion Container Creation.

The next step was to explore the best approach for integrating Ansible with Docker to closely mirror a production environment. We maintained our manual provisioning approach and focused on three key integration strategies.

Option 1 involves having Ansible manage containers directly through the Docker network, where all services (bastion, ansible, web, db) operate within the same network. Ansible handles the management of the web and db containers using their container names or IPs, with the bastion server acting as a jump host only when necessary. This approach treats each container as an independent host, with Ansible responsible for installing and configuring the necessary software.
Option 2 leverages the community.docker.docker_container_exec module to execute commands within Docker containers via Ansible playbooks. This method allows for application installation and configuration tasks to be performed directly inside the containers.
Option 3 involves running only the bastion and Ansible services in Docker, while using Ansible to provision the web and db services. Ansible connects to these containers through the bastion server, allowing it to manage and configure the web and db as external resources.

When comparing these options, Option 1 manages applications within containers at the application layer, offering fine-grained control and simplifying setup in a unified environment. Option 2 operates at the Docker layer, providing greater flexibility and portability, ideal for quick deployments. Option 3 provides the best isolation between services, closely simulating a production environment with enhanced security, but it requires a more complex setup.

After careful consideration, we decided to proceed with Option 1, which shifts most configuration tasks from the Dockerfile to Ansible playbooks. As I write this post, I am in the process of implementing these playbooks to configure the containers. You can follow the ongoing development in this repository.

Acknowledgments

This experience has provided me with practical skills in implementing real-world DevOps projects. I truly enjoy learning all this knowledge outside of my daily job and dedicating my personal time to something meaningful, which is often not covered in school. If this project succeeds as a proof of concept, I can gather more feedback from users, specifically open-source developers, to enhance this setup. I mentioned this in my previous blog post, but I can’t emphasize enough how grateful I am to Shafiya, Timid Robot, and Sara for their guidance, and to Google Summer of Code for giving me the opportunity to contribute to open source. As a content creator who both produces and enjoys various open content online, I am incredibly excited and honored to contribute my technical expertise to CC. Thanks to CC’ impact on society, I am committed to continually advancing my technical skills and supporting this organization in the long term. I look forward to continuing my involvement in the open-source community!

Automating Quantifying the Commons: Part 2

2024-08-22T00:00:00Z

Introduction: Midterm Recap

This post serves as a technical journal for the development process of the concluding stretch of Automating Quantifying the Commons, a project initiative for the 2024 Google Summer of Code program. Please visit Part 1 for more context if you haven't already done so.

At the point of the midterm evaluation, I successfully completed Phases 1, 2, and 3 (fetch, process, and report) of the Google Custom Search (GCS) data source, with a working report README generation for each quarter. My documented goal for the second half of the period was to complete a baseline automation software for these processes across all data sources.

Development Process

I. Midpoint Reassessment

If you read my previous post, you might have seen that my next steps involved completing the phases for the remaining data sources. However, I soon realized that the GCS phases, along with the base analysis and visualization code from the Data Discovery Program, already serve as a standard reference for these tasks. Given that the primary goal of this project is to develop automation software for these phases, my mentor suggested shifting the focus of the final time period towards programming the Git functions for automation. This approach, which will require more time and effort, will ensure that anyone working on the remaining data sources can easily integrate them using the existing code as a reference.

II. GitHub Actions Development

We defined GitHub Actions to host our CI/CD workflows, and since I had never used YAML before, I needed to learn and familiarize myself with this new technology. Learning YAML presented challenges, particularly in developing the Git automation. My mentor emphasized focusing on the Git programming due to these challenges. For example, I encountered errors during workflow runs without clear ways to debug them.

In my previous post, I shared three strategies that helped me familiarize myself with new technology during the first half of the summer. Here, I’m sharing two additional strategies that were particularly useful for GitHub Actions programming:

GitHub Actions Extension for Visual Studio Code: As I was using VSCode for development, I initially struggled to debug issues during workflow runs. Discovering the GitHub Actions Extension for VSCode was a game-changer. This extension highlights issues in the workflow, making it much easier to diagnose and fix problems. I highly recommend searching extensions for any development task, as having relevant tools can make programming much easier.
Creating Mini-Tasks for Experimentation: I set up my own GitHub repository with minimal, functional code to experiment with GitHub Actions in a low-risk environment. This approach facilitated easier debugging and comparison, helping me understand why certain things weren’t working. Although I gained more repository privileges after being accepted for GSoC, I still didn’t have the same access level as my mentor. By using a separate repository, I gained a better understanding of GitHub Actions and was able to interpret error logs more effectively. For instance, I realized that the automation wasn’t working initially due to outdated repository secrets, which I discovered without access to the secrets.

After successfully compiling the initial steps, I focused on refining the scripts for optimal performance. I moved the commit functions into a shared module, which reduced the risk of crashes by allowing functions to be called within individual scripts rather than directly in the YAML workflow. Once the workflows ran successfully, I implemented Cron functions to schedule them quarterly.

III. Engineering a Custom Error Handling and Exception System

A key innovation in this project was the creation of a custom QuantifyingException class tailored specifically for the unique needs of the data pipeline. Unlike generic exceptions, this specialized exception class was designed to capture and handle errors that are particular to the Quantifying process, such as data inconsistencies, API rate limits, and file handling errors. By centralizing these exceptions within QuantifyingException, I ensured that all three phases could consistently manage errors in a coherent and structured manner. While testing this system across all phases, I made sure to purposely include "edge-case" errors upon commits to guarantee that the system could handle all these errors.

Upon completion of a robust error and exception handling system, I completed all phase outlines of the remainder of the data sources. For fetching data from these sources, I have developed codebases combining the GCS fetch system and the original Data Discovery API fetching for a complete fetching system. However, it should be noted that I have not actually fetched data from these APIs using the new codebase, as Timid Robot will undertake an initiative to add GitHub bots for the API keys after the GSoC period — this is due to best practice purposes, as it is fundamental to create dedicated accounts for clear API usage and automated git commits. Therefore, these fetch files may need to be slightly tweaked after that, which will be discussed in Next Steps. However, I have made sure to utilize fake data to ensure that the third phase successfully generates reports within the respective README file for ALL data sources.

IV. Finalized Flow of System + Data

In Part 1, I had shared the initial data flow diagram (DFD) for arranging the codebase. By the end of the program, however, the DFD and the overall system had solidified into something different. Below is the final diagram for data flow, which establish an official framework for future endeavors.

Final Conclusions

I. All Deliverables Completed Over the Course of the Program

Although this 12-week period allowed significant expansion of the Quantifying codebase, there were still time and resource constraints that we had to consider; primarily, the lack of data we could collect using the given APIs over this time period. However, as mentioned earlier, given strategic implementations, I was able to still complete the summer goal of developing a baseline automation software for data gathering, flow, and report generation, ensuring script runs on a quarterly basis. The Next Steps section will elaborate on how this software will be solidified over the upcoming quarters and years.

130+ commits, 7,615+ net code additions, and 360+ hours of work later, I present ten pivotal deliverables that I have completed over the summer period:

Deliverable	Description
Phase 1: Fetch Data	Building on previous efforts in the Quantifying initiative, this phase efficiently fetches raw data from various data sources using APIs. The retrieved data is then stored in a structured CSV format, preparing it for processing and analysis.
Phase 2: Process Data (Outline)	This phase focuses on analyzing the fetched data between quarters. Since only `2024Q3` data (07/01/2024 - 09/30/2024) could comprehensively be generated during the summer period, a psuedocode outline of analysis was developed. Although this phase will be further solidified as more quarters and years pass by, a base error system was tested and implemented during the GSoC period to ensure thoroughness for this phase.
Phase 3: Generate Reports	The final phase successfuly creates visualizations and reports based on the generated datasets. These reports are designed to present key findings and trends in a clear, concise manner, and have been designed to automatically be integrated into a quarterly README file to provide a comprehensive overview of license data across data sources.
Shared Module	Created a singular, shared module to organize and streamline the codebase, allowing different directories, paths, and components to be imported through that module across different files.
Directory Sequence (OS)	Using Operating System (OS) Modules, the codebase effectively facilitates the interaction between all three phases, ensuring smooth communication of 10 different data sources with their respective data storages.
Automation using GitHub Actions CI/CD	All three phases of the project — data fetching, processing, and reporting — have been automated using YAML scripts in GitHub Actions. This CI/CD pipeline ensures that every update to the codebase triggers the entire workflow, from data retrieval to the generation of final reports, maintaining consistency and reliability across the process. Cron functions are used to ensure that these scripts are run every quarter in a timely manner.
Custom Error & Exception Handling System	Implemented a custom exception system that centralizes the error-handling logic, keeping the codebases more specific, maintainable, and consistent overall. This system has been thoroughly tested and verified across all three phases.
Project Directory Tree	Added a structured layout of the project (hierarchical representation of directories and files with descriptive comments), which provides developers with a clear understanding of the project's organization and help them navigate through different components easily.
Data Flow + System Design	Finalized an overall data flow and system design diagram to establish an official framework for the codebase.
Comprehensive Documentation	This document was developed to serve as a reference guide for any contributors having questions or needing detailed clarification on specific topics within the Quantifying codebase — each section has its own page with expanded information. It also includes external references and documentation regarding the languages and tools used for this project.

II. Acknowledgements, Impact, Next Steps

This project would not have been possible without the constant guidance and insights of my mentors: Timid Robot Zehta (lead), Shafiya Heena (supporting), and Sara Lovell (supporting). I appreciate how they created a safe space for working since the very beginning. I've never felt hesitant to ask questions and have never felt out-of-place working in the organization, despite my introductory-level skillset at the start. In fact, this allowed me to feel open to ask questions and be able to undertake side-projects that facilitated my growth. I truly believe that being able to work in an environment like this has played a large role in my ability to perform well, and this was the sole reason for the overall fast progress and depth of my deliverables.

As for overall impact, it is very evident that Creative Commons is integral to facilitating the sharing and utilization of creative works worldwide. With over 2.5 billion licenses globally, Creative Commons and its open-source inititives hold heavy impact, promising to empower researchers, policymakers, and stakeholders with up-to-date insights into the global usage patterns of open doman and CC-licensed content. Therefore, I'm looking forward to witnessing the direct influence this project holds in paving the way for future advancements in leveraging open content licenses globally. I am extremely grateful and honored to be able to play such a major role in contributing to this organization, and am excited to see future contributions I facilitate alongside other CC open-source developers.

As for next steps, I am opening several post-GSoC issues in the Quantifying repository that can be worked on by any open-source contributor. These issues cover some of the necessary adjustments that need to be made once we cross certain time periods and codebase additions. If you're interested in getting involved, please visit the Issues page linked for your convenience. Your contributions will be invaluable as we continue to enhance and expand this project, and I’m eager to see the innovative solutions and improvements that will unfold these upcoming years!

Additional Readings

Automating Quantifying the Commons: Part 1 | Author: Naisha Sinha | Jul. 2024
Data Science Discovery: Quantifying the Commons | Author: Dun-Ming Huang (Brandon Huang) | Dec. 2022

Continuing Open Collaboration: GSoC 2024 With Creative Commons

2024-08-22T00:00:00Z

As I reach the final phase of my work on the Creative Commons Resource Archive under this program, I’ve been thinking about how far we’ve come since the beginning. We started with the idea of modernizing the resource archive website, and we have built features that make it safer and more accessible. This journey has had its challenges, but it’s also been very rewarding. In the first post, we discussed the early steps that set up this project. Now, as we are in the final weeks, I’m excited to share the progress we’ve made to turn the Resource Archive into a valuable tool for the community.

Join me as I take you through this complete journey of covering new features, the hurdles we’ve overcome and the final product that I hope will continue to grow and serve the open knowledge community.

Transitioning From Midterm

After completing the Midterm milestone, the focus was to utilize the learnings and experience I got across the past weeks to complete the tasks mentioned in the timeline in the least time possible. My mentor suggested not to hurry up things too much, but just to work at a comfortable higher pace. This way, we can have some room for the implementation of stretch goals for the project. The midterm review provided valuable feedback, which helped guide the next steps. With a solid foundation in place, it was time to tackle the more complex challenges and polish the user experience. From enhancing the search functionality, filtering experience to improving the accessibility, the post midterm work aimed to ensure the resource archive becomes a great tool to serve the community.

Completing The Timeline Tasks - Weeks 7, 8 and 9

These three weeks were planned with the aim of completing the timeline tasks to focus on further goals of the projects. The UI-related tasks included Submission page, A guide for the newcomers to submit resources, and working on the filters.

Submission Page UI Changes

The submission.html page is responsible for the area where contributors come to contribute to the resource archive with their resources about Creative Commons or Open sharing of knowledge in general. With the help of the PR#315, The following tasks were performed :

adds a new context to the element, named submit-page.
refactors the whole html code for submission.html with semantic code.
makes the page responsive, by adding media queries wherever needed.
adds a step by step written guide including images, for submission of resource for new github users.
ensures the page meets current CC aesthetics.
adds documentation for better understanding and maintainability.
formats the files with prettier code formatter.

Submission guide For Newcomers

For people not familiar with GitHub or Opening Pull Requests on GitHub, a comprehensive guide was added with step by step process to submit a resource to the resource archive. The guide included instructions to fork, clone the repository and also Open the PR by committing to the repository. This was accompanied with well-labeled images for better understandability. This work was achieved with the help of PR#315. This was the final addition to the submission.html page and the whole tasks related to this page were completed by this.

Filters Placement and Functioning

The resource archive utilizes filters to select similar resources. These filters are grouped in the form of three categories, TOPIC, MEDIUM and LANGUAGE. Each category has some filter options to choose from. In the previous iteration of the resource archive site, the category filters were placed in the middle of the page, and they also did not have any icon for the indication of a selected filter. The PR#316 makes the filters responsiveness, and more easy to access by performing the following tasks:

adds semantic html to index.html and all.html
removes the filters from index.html.
removes inline styles from html pages.
adds a new context to listing.html.
works on the see-all-resources link.
adds checkbox in place of [x] in category filters.
makes the filters as a sidebar.
makes the whole category filters responsive.
Re-works on the media-query breakpoints.
formats the code with prettier code formatter.
adds documentation for the index.html, all.html and style.css files.

Stretch Goals And Ideation - Weeks 10, 11 and 12

After the completion of the tasks assigned in the timeline, we shifted the focus to the Stretch goals suggested in my proposal, and also by my mentor (Sara). There were 3 major goals that were considered for a discussion. These were, Implementation of Search Functionality through Lunr.js, Improving accessibility through the inclusion of ARIA attributes to the elements in the website, and The use of GitHub API to automate the process of submission of resources to the site. Out of these three, the goals that were to be implemented were ARIA accessibility and LUNR.js search functionality. This was decided keeping in mind the scope of the project and the desired limit of complexity we wanted the site to have at this point.

Aria Accessibility and Search Functionsality - LUNR.js

My mentor suggested that I read about WAI-ARIA accessibility to gain insights about the process and better select the number of attributes and features we need to implement. I studied about this thoroughly and also watched some videos on the topic. I realized about the importance of having these features in our site and how greatly they impact the accessibility for different users. Apart from this, we wanted to implement a search feature for the resources with the help of a lightweight searching library like LUNR.js. I started to read about the library and its execution process from various sources, majorly from the LUNR Documentation present in their site. After reading it and a bit of panning, I started to code for this feature. The goal was to keep the UI similar to the CC Search feature present in the header of many Creative Commons sites.

Issues Solved From Midterm To End

The issues relevant to the project which have been solved in the period between midterm and final week are listed below:

#52 - use checkbox for resourcenavtopicknown
#61 - change UI of the homepage
#72 - UI refinement of the website
#119 - adding icon on filter text
#274 - Improve the UI of submission page with vocabulary
#306 - Language List Columns Collapsing on Website
#310 - Add a step by step guide for submitting resources
#311 - html markup contains inline styles
#313 - improve mobile view layout for filter columns
#314 - remove extra white space between main content and footer
#318 - Links in submit page open on same page and spelling mistake-comapre

Future Plans And Execution

The future plans include the execution of the Stretch Goals we discussed in the later weeks of the project. Firstly, I will be working on the LUNR.js search functionality and will be trying to complete this in the 13th week, and also the contributions on the ARIA accessibility are welcome on GitHub. Also, apart from these fixed goals, I aim to remain engaged with the community for the years ahead. I have planned to keep contributing to the organization - Creative Commons, and especially the repository - CC-Resource-Archive for as long as I can. I will be contributing in the form of issues, pull requests and also code reviews. This is the first organization I got to connect professionally with, and I aim to continue to be a part of this mission of Sharing of Open Knowledge.

Personal Growth And Thoughts On Completion

As I mentioned in my previous blog post, Being a part of Google Summer of Code was a very big deal for me. With an organization like Creative Commons, this could not have been better. I did not only know about the organization before all this GSoC 2024 preparation, but also resonated with the idea and mission behind it, and was grateful for the learning opportunities it creates for people across the world. Being at the final week of this program makes me emotional as I had a really good time with the mentors and the project. In the weekly meetings we conducted, the amount of motivation I got every single time talking with my mentor was unmatched. I was a complete newbie in terms of professional work experience, and this is the way everything should have been. I am a better individual at this point, and far more experienced. I think I will be able to guide my juniors in a better way from now onwards. This program also instilled in me a newfound confidence that is needed to take on tough tasks. I believe the program is less about coding skills and more about the self-improvement journey one has with their mentors and fellow contributors. One more thing which caught my interest is reviewing the Pull Requests of other contributors. My mentor suggested that I try reviewing pull requests of new contributors for experience. “This is a great learning opportunity for you” as they said it. Exactly as I was told, this was indeed a great and enjoyable opportunity.

Conclusion

Gratitude And Acknowledgements

Sara Lovell, Timid Robot Zehta and Shafiya Heena were the best mentors I could have asked for this project program. My primary mentor, Sara, always encouraged me to be on track whenever I lagged behind in work. Considering this was a straightforward project, I did not predict the learning opportunities to be this much in number. I will always be grateful for these 12 weeks of support, learning and growth. Thank you !

For Future Contributors

All the contributors that are hoping to contribute to this repository, or this organization, I welcome you with all my heart. If you are targeting to get selected in an Open Source mentorship program, that is a great idea. But do not just contribute to Open Source for the sake of resume building and stipend. I agree they are very good benefits, but Open Source is simply much more than this. Once you contribute to Open Source, you will fall in love with the support you get from this community, just like I did. You can find me on GitHub and on the CC-Resource-Archive repository mainly. Let’s have the conversation there!

Local Environment Creation using Ansible and Docker: Part 1

2024-07-18T00:00:00Z

This project explores how Creative Commons (CC) uses Ansible, an automated system administration tool, to build a local development environment. It is part of Google Summer of Code (GSoC) 2024.

Project Objective

Project Background

This project aims to establish a local development environment that closely mirrors our production setup at CC. Currently, CC uses Salt Stack for configuration management. However, the team is evaluating other tools for various reasons. In this project, we explored Ansible, renowned for its simplicity and robust automation capabilities. We combined Ansible with Docker containers to streamline and secure development processes, creating lightweight, isolated environments for running applications.

Challenges and Learning Opportunities

Before this project, I didn't have exposure to professional DevOps practices, so this project has been a significant learning experience for me. It focuses on the deployment phase of the DevOps lifecycle, particularly provisioning (setting up servers) and configuration management (managing software and settings). During our early stage exploration, we performed manual provisioning and concentrated on utilizing Ansible for configuration management. Our primary goal is to containerize existing applications, packaging them with their dependencies into Docker containers. Ansible itself operates within a container and manages other containers via SSH.

This architecture diagram is designed by my mentor and project lead Shafiya.

Week-by-Week Progress

I began by following the Docker and Ansible setup guides from the official documentation to successfully deploy an initial ansible container in Creating Initial Structure for Ansible. This step was crucial for gaining a foundational understanding of Ansible's basic functionality and setup within a containerized environment.

In the second week, I separated the existing index-dev repository, which is the local development environment for current CreativeCommons.org, into individual containers for the web server and database server in Setting Up Ansible Environment and Hosts. At the same time, I started investigating the setup of a Bastion server and its integration into our system, aiming to enforce a security-focused approach for controlling access to a private network.

In the third week, I established SSH access between the local machine and web, database, and ansible servers with my mentor Shafiya's guidance in Setting Up SSH For web and database and Integrate with ansible. This step was crucial for enabling secure, automated management of the containers from the Ansible container. One important lesson I learned from Shafiya is to build things from scratch, making frequent commits that document your thought process, rather than trying to put everything together at once and complicating matters.

In the fourth week, I started writing Ansible playbooks and moved several configurations originally located in the web Dockerfile to the playbook. Combining Dockerfiles and Ansible playbooks is a common best practice: Dockerfiles are responsible for building the base image, including the OS and basic tools, while Ansible playbooks handle the application and service configurations. However, this part took longer than expected, so we had to extend the work for one more week. Looking back, it was likely because I had no previous experience in developing using LAMP (Linux, Apache, MySQL, PHP) stack, and didn't know how to properly configure each component, which prevented me from successfully launching the services. As a result, I had to review the index-dev repo and what Shafiya and I did in the previous week, and finally got the service to start up correctly in Creating A Playbook to Configure Wordpress Over Apache2.

Communication and Collaboration in Open Source

The CC team, including mentor Shafiya and team members Timid Robot and Sara, provided valuable insights into system design and broader architectural considerations. Weekly sync meetings and the flexibility to schedule 1:1 sessions facilitated smooth progress. The team provided clear documentation and actively engaged in public Slack channels, making it easy for any contributor to get involved and stay informed.

Conclusion and Next Steps

Moving forward, the focus will be on refining the Ansible playbooks, addressing any bugs or issues, and working on security and scalability concerns. The goal is to deliver a robust and efficient local development environment that closely mirrors the production setup. I'll continue contributing to the community and providing detailed documentation to support future developers in this project.

Empowering Open Knowledge: GSoC 2024 With Creative Commons

2024-07-10T00:00:00Z

Hello everyone! My name is Ayush Sahu, and I am thrilled to announce that I have joined Creative Commons this summer through the Google Summer of Code (2024) program. As a passionate advocate for open knowledge and a firm believer in the power of collaborative innovation, I am grateful to contribute to an organization that has been championing the free exchange of information and creativity for years.

I was inspired to collaborate with Creative Commons because of the profound impact it had on me personally. As a child creating videos for my YouTube channel, I was immensely grateful for the resources provided by Creative Commons. Their promotion of free and open knowledge enabled me to access high-quality content without the constraints of traditional licensing, fostering my creativity and passion for sharing information. This experience instilled in me a deep appreciation for the organization and its mission.

The Project I Am Working On

The project - Modernize CC Resource Archive focuses on implementing a comprehensive visual overhaul to the Resource Archive to align with current Creative Commons aesthetics and functionality standards. Utilizing the Internal Design System (Vocabulary), the project aims to upgrade the visual design, implement semantic, accessible, and standards-compliant HTML, CSS, and JavaScript, and improve user experience (UX) for resource submission while ensuring site stability on GitHub Pages. Through these efforts and solid documentation, the revamped Resources Archive will meet modern standards, enhance usability, and facilitate maintainability for both users and developers.

Community Bonding Period

The community bonding period has been an incredibly enriching experience. During this time, I had the opportunity to meet my mentors, familiarize myself with the project, and engage with the vibrant community behind Creative Commons. I participated in meetings and discussions, which have deepened my understanding of the organization's values as well as the codebase. The warm welcome and the wealth of knowledge shared by the community have been truly inspiring.

Environment, Code & Ideation - Weeks 1, 2 & 3

These were the initial weeks of the project which went into testing the development environment, planning upcoming UI changes and getting acquainted with the working process. Firstly, my project mentor Sara guided me through my first contribution in the coding period. I was granted member status at the Creative Commons Organization on GitHub, which was both new and exciting for me.

The key achievements were:

PR#266 - Updated the docker-compose.yml file to the current spec. With the help of my mentor, I opened this first pull request in the coding period. The file was out of specification, as the version element at the top of docker-compose.yml file was just informative.
Testing Docker Configurations: With immense help from mentors Sara and Timid Robot, I got the Docker environment ready for development.
Learned more about Jekyll and read the Vocabulary code. Got familiar with classes in vocabulary.css and the custom CSS variables in library-vars.css.
Accessibility Improvements: Learned about keyboard navigability and optimizing the website for better accessibility using semantic HTML and appropriate CSS properties.
Issue Listing: Identified and listed relevant issues related to semantic code and UI changes. Also added some issues as a to-do list, as suggested by my mentor.
Reviewed the present structure of the files, and worked on ideas to improve the structure for better understandability and grouping of similar files.

At the end of these initial weeks, I realized that I have spent enough time on understanding the code and planning on things. But as my mentor suggested, things will get smoother once we start working on them practically. So I decided to increase the pace of work in the upcoming weeks to get the planned tasks executed.

Execution, Updation & Refactor - Weeks 4, 5 & 6

As the midterm evaluation approached, we held weekly review meetings to plan changes and contributions. The pace picked up in weeks 5 and 6, resulting in several presentable pull requests dedicated to UI changes and code refactoring. Notable tasks executed include:

Improving File Structure

With discussion with my mentor, I improved the file structure in the codebase for better understandability and maintainability. After updating the structure, the paths to all the files that were changed were modified. This was achieved by a group of Pull Requests that were created catering to the issue. The pull requests were:

PR#280 - Adds footer.html to the _includes directory.
PR#281 - Includes footer.html to all the pages of the site.
PR#282 - Shifted an-explanation-of-creative-commons to _resources.
PR#289 - Improves the file structure in the codebase.
PR#292 - Updates the paths to downloadable resources and PDFs.
PR#296 - Updated the resource-template with new paths for images.

Listing Page UI Changes

The listing.html page is responsible for the display of resource cards on the index.html and all.html pages. The resource cards had an outdated visual setup and needed to be aligned with the Internal Design System of Creative Commons known as Vocabulary. Through the PR#298, I performed the following tasks:

Refactored the html structure of the resource card to IMAGE - TITLE - BLURB.
Utilizing vocabulary, enhanced the style for thumbnail list in listing.html. Worked on the grid structure in style.css.
Likewise, worked on enhancing style for the thumbnail box, thumbnail title, thumbnail image and thumbnail blurb.
Worked on Fonts, colors, background colors, etc. according to vocabulary.
Assigned properties like --underline-background-color from vocabulary into style.css.
Formatted the style.css and listing.html files with prettier.
Fixed the responsiveness of the resource cards.
Added Documentation in style.css for understandability.

And through the PR#302, the following tasks were completed:

Added a heading to the page.
Added clear documentation about various sections in the file.
Formatted the code with prettier code formatter.

All these changes gave the website a new look, aligning more closely with the standard Creative Commons design schemes.

Listing Page (All) Javascript Changes

The javascript code in listing.html file resided in the <head> section of the page. The code was outdated and was lacking the ES6 Javascript concepts. For example, there were uses of var keyword, document.write() method, etc.. The code was responsible for a number of tasks related to the display of resources. It extracted the user-selected categories from the URL and then returned them as variables. Also, the javascript code was responsible for displaying the resources which contained the selected categories. Through the PR#300, the following tasks were completed:

Updated the functions and code to follow ES6 javascript concepts.
Replaced the document.write() method with Document Object Manipulation. The document.write() is old and not preferable.
Utilized the javascript DOM for all the tasks related to filtering of resources in listing.js.
Assigned checks to the categories selected by the user (which are extracted through the URL), sanitizing the input and preventing any attacks on the website.
Added proper documentation for all the functions and sections of code for better understandability.

Resource Page UI Changes

The resource page is a layout to show various resources that are submitted in the resource archive. This layout page accepts values from the front matter of various resources. This page was overall enhanced in terms of alignment to Creative Commons’ Design System. The PR#304 performs the following tasks:

Refactors the whole code for resource.html page by implementing semantic HTML.
Improves the styling of the page in styles.css, by utilizing vocabulary.
Makes the page responsive.
The inspiration is drawn from the Vocabulary Blog Post Page.

These three weeks saw the most significant work being merged, resulting in a refreshed interface. Despite a slow start, consistent effort and mentor support helped me catch up by the midterm evaluation, making these weeks a great learning experience.

Issues Solved Till Now

The issues relevant to the project which have been solved until now are listed below:

#17 - upgrade JS code in listings.html
#176 - make thumbnails responsive
#242 - add footer in submission and resource pages
#265 - The docker-compose.yml file currently out of spec
#267 - Improve documentation for Dockerfiles
#269 - relocate footer code to separate file ‘footer.html’ for reuse
#273 - Resource file in the wrong location
#276 - Inconsistent docker behavior - Parsing Gemfile
#283 - Unnecessary google analytics function in listing.html
#285 - Unnecessary google analytics function in resource and submission.html
#287 - The file structure in the codebase can be improved. (re-structuring)
#288 - The style.css file is not properly organized and lacks documentation
#290 - The download [pdf] file links at bottom of resources aren't working
#293 - The resourcetemplate.md needs to be updated.
#297 - Change the design of resource cards on homepage using vocabulary
#165 - section heading for resource cards
#301 - Add proper documentation to listing.html, refactor for structure
#101 - Organize code with proper indentation
#41 - UI/UX for resource page
#272 - unwanted underline in the resource page

My Experience - From Getting Selected To Midterm

Getting selected to Google Summer of Code was honestly a very big deal for me. When I joined my university for my undergraduate degree, our seniors introduced us to two guys who got selected in GSoC that year. They were given immense importance and respect by our seniors and also my batchmates. From that instance I got to know that being a GSoC Contributor is a very prestigious thing for someone hoping to start their career. Having zero background knowledge in programming, I thought it’s not something that I should aim for, and leave it to the guys who already are pro at coding. But the dream of being a GSoC contributor just stuck somewhere in my head. Fast forward to my third year at the university, I became good with frontend development as it was something that naturally excited me. After working hard for some months, I was finally selected for the GSoC 2024 program with Creative Commons.

Now after being selected to GSoC, I was very happy and satisfied as it was a dream come true. As a result of this, I could not do the amount of work that I should have, in the initial weeks of the program. I had weekly review meetings with the org mentors, who constantly supported and encouraged me to catch up to the planned timeline of tasks. As a result of their motivation and some extra efforts, I was able to finish the tasks that needed to be done till the midterm evaluation. At this point I feel really good that we are successful in completing the tasks till the midterm evaluation. The best thing about this is that it was always a combined effort. I am planning to execute more tasks in the other half of the period, than we have till now. I’ll be faster as I have become really comfortable working with my mentors in these six weeks.

Gratitude and Acknowledgements

I would like to express my heartfelt gratitude to my mentors and the entire Creative Commons community for giving me this incredible opportunity. Your support and guidance have been invaluable. Special thanks to my mentor Sara Lovell (Possumbilities) for the constant support that I received from you all the time. I am really grateful for not only the technical help, but also the motivation, support and encouragement I got from your side. Also Timid Robot and Shafiya Heena were always present there whenever I needed them. Be it the weekly review meetings, or my confusion related to the development environment, I never felt I’m alone in this . I am excited to work further under your guidance and contribute to the shared vision of Creative Commons.

Join The Discussion

There are numerous ways you can join the discussion and contribute to the project. Whether it’s by providing feedback, contributing to the codebase or simply spreading the word about open knowledge, your participation is highly encouraged. You can check out our github repository here, to find the codebase and join the discussion over there.

Automating Quantifying the Commons: Part 1

2024-07-10T00:00:00Z

Introduction

Quantifying the Commons, an initiative emerging from the UC Berkeley Data Science Discovery Program, aims to quantify the frequency of open domain and CC license usage for future accessibility and analysis purposes (Refer to the initial CC article for Quantifying here!). To date, the scope of the previous project advancements has not included automation or combined reporting, which is necessary to minimize the potential for human error and allow for more timely updates, especially for a system that engages with substantial streams of data.

As a selected developer for Google Summer of Code 2024, my goal this summer is to develop automation software for data gathering, flow, and report generation, ensuring that reports are never more than 3 months out-of-date. This blog post serves as a technical journal for my endeavor till the midterm evaluation period. Automating Quantifying the Commons: Part 2 will be posted after successful completion of the entire summer program.

Pre-Program Knowledge and Associated Challenges

As an undergraduate CS student, I had not yet had any experience working with codebases as intricate as this one; the most complex software I had worked on prior to this undertaking was most probably a medium-complexity full-stack application. In my pre-GSoC contributions to Quantifying, I did successfully implement logging across all the Python files (PR #97), but admittedly, I was not familiar with a lot of the other modules that were being used in these files. As a result, this caused minor inconveniences to my development process from the very beginning. For example, not being experienced with operating system (OS) modules had me confused as to how I was supposed to join new directories. In addition, I had never worked with such large streams of data before, so it was initially a challenge to map out pseudocode for handling big data effectively. The next section elaborates on my development process and how I resolved these setbacks.

Development Process (Midterm)

I. Data Flow Diagram Construction

Before starting the code implementation, I decided to develop a Data Flow Diagram (DFD), which provides a visual representation of how data flows through a software system. While researching effective DFDs for inspiration, I came across a technical whitepaper by Amazon Web Services (AWS) on Distributed Data Management, and I found it very helpful in drafting my own DFD. As I was still relatively new to the codebase, it helped me simplify the current system into manageable components and better understand how to implement the rest of the project.

This was the initial layout for the data directory flow; however, the more I delved into the development process, the more the steps changed. I will present the final directory flow in Part 2 at the end of the program.

II. Identifying the First Data Source to Target

The main approach for implementing this project was to target one specific data source and complete its data extraction, analysis, and report generation process before adding more data sources to the codebase. There were two possible strategies to consider: (1) work on the easier data sources first, or (2) begin with the highest complexity data source and then add the easier ones later. Both approaches have notable pros and cons; however, I decided to adopt the second strategy of starting with the most complex data source first. Although this would take slightly longer to implement, it would simplify the process later on. As a result, I began implementing the software for the Google Custom Search data source, which has the largest number of data retrieval potential among all the other sources.

III. Directory Setup + Code Implementation

Based on the DFD, Timid Robot (my mentor) and I identified the directory process to be as such: within our scripts directory, we would have separate sub-directories to reflect the phases of data flow, 1-fetch, 2-process, 3-report. The code would then be set up to interact between systems in chronological order. Additionally, a shared directory was implemented to optimize similar functions and paths.

1-fetch

As I mentioned in the previous sections, starting to code the initial file was a challenge, as I had to learn how to use new technologies and libraries on-the-go. As a matter of fact, my struggles began when I couldn't even import the shared module correctly. However, slowly but surely, I found that consistent research of available documentation as well as constant insights from Timid Robot made it so that I finally understood everything that I was working with. There were a few specific things that helped me especially, and I would like to share them here in case it helps any software developer reading this post:

Reading Technical Whitepapers: As I mentioned earlier, I studied a technical whitepaper by AWS to help me design my DFD. From this, I realized that consulting relevant whitepapers by industry giants to see how they approach similar tasks helped me a lot in understanding best practices to implementing the system. Here is another resource by Meta that I referenced, called Composable Data Management at Meta (I mainly used the Building on Similarities section to study the logical components of data systems).
Referencing the Most Recent Quantifying Codebase: The pre-automation code that was already implemented by previous developers for Quantifying the Commons was the closest thing to my own project that I could reference. Although not all of the code was relevant to the Automating project, there were many aspects of the codebase I found very helpful to take inspiration from, especially when online research led to a dead end.
Writing Documentation for the Code: As a part of this project, I assigned myself the task of developing documentation for the Automating Quantifying the Commons project (can be accessed here!). Heavily inspired by the "rubber duck debugging" method, where explaining the code or problem step-by-step to someone or something will make the solution present itself, I decided to create documentation for future developers to reference, in which I break down the code step-by-step to explain each module or function. I found that in doing this, I was able to better understand my own code better.

As for the license data retrieval process using the Google Custom Search API Key, I did have a little hesitation running everything for the first time. Since I had never worked with confidential information or such large data inputs before, I was scared of messing something up. Sure enough, the first time I ran everything with the language and country parameters, it did cause a crash, since the API query-per-day limit was crossed with one script run. As I continued to update the script, I learned a very useful trick when it comes to handling big data: to avoid hitting the query limit while testing, you can replace the actual API calls with logging statements to show the parameters being used. This helps you understand the outputs without actually consuming API quota, and it can help you identify bugs more easily.

A notable aspect of this software is the directory organization. Throughout the process, I designed it so that the datasets are automatically stored within their respective quarter's directories rather than being stored altogether. This ensures efficient organization in order for users to easily access in the future, especially when the number of datasets multiplies.

Upon successful completion of basic data retrieval and state management in Phase 1, I felt much more confident about the trajectory of this project, and implementing future steps and fixing new bugs became progressively easier.

2-process

The long-term goal of the Quantifying project is to have comprehensive datasets for each quarter, encompassing license data that scales up to millions and even billions. For the 2-process phase specifically, the aim is to analyze and compare data between quarters to be able to display in the reports. However, given our Google Custom Search API constraints as well as the time period we're working with for the GSoC period (most of this period is mainly 2024Q3), it is not possible to have a fully completed Phase 2. However, in order to deploy as complete of an automation software as possible, I have set up a basic psuedocode that can be implemented and built upon by future development efforts as more data is collected in the upcoming quarters/years.

3-report

As mentioned earlier, the Google Custom Search API constraints made it difficult to create a comprehensive and detailed dataset, so I plan to initiate the development of a more fletched-out Google Custom Search post-GSoC, when more data can be accumulated (discussed further in the next section). As of now, there are three main completed report visualization schemes: (1) Reports by Country, (2) Reports by License Type, and (3) Reports by Language. Although the visualizations are basic in design, I made sure to incorporate accessibility into the visualizations for a better user experience. This included adding elements like labels on top of the bars with specific number counts for better readability and understanding of the reports. In addition, I included three key features in the reports codebase to cater to various possible needs of the report users.

Key Feature #1: I implemented command line arguments in which users can choose any quarter to visualize, as I believe this would be useful for anyone in need of individual reports from previous quarters, not just reports from this quarter.
Key Feature #2: Successfully stores reports into the data reports directory specific to each quarter for optimal organization (similar to the dataset organization in Phase 1). In this way, reports from one quarter will not be mixed up with reports from another quarter, making it easier for users to navigate and use.
Key Feature #3: The program automatically generates and/or updates an individual README file for each quarter's reports. This README organizes all generated report images within that quarter into one page, alongside basic report descriptions.

Mid-Program Conclusions and Upcoming Tasks

Overall, my understanding and skillset for this project increased ten-fold after completing all the phases for Google Custom Search. Going into the second half of the Google Summer of Code program, I expect that I will complete the future data sources at a more efficient and faster rate, given the license data sizes and my heightened expertise. In fact, as of now (the midterm evaluation point), I have completed a relatively detailed Phase 1 for Flickr, which only involves 10 licenses. My biggest takeaway from the first half of the coding period is that rather than developing a basic querying process and adding on later, it's easier to start off with a complex and detailed version before moving on to Phases 2 and 3. Additionally, using the shared module within the scripts can be very beneficial to simplify the coding process.

In the second half of the GSoC program, I plan to keep both of these takeaways in mind when developing scripts for the rest of the data sources. On a formal level, the final goal for the end of GSoC 2024 is to have a working codebase for Phases 1, 2, and 3 of all data sources, including a completed automation setup for these scripts. Due to the effectiveness of the current directory organization and report generation features, I will be standardizing them across all data sources.

Finally, after the software is complete to the extent that is possible during the GSoC period, I plan to raise issues in the repository respective to all the next steps that could be taken post-GSoC by open-source developers for a more comprehensive software system.

So far, my journey at Creative Commons has significantly enhanced my skillset as a software developer, and I have never felt more motivated to take on more challenging tasks. I'm looking forward to more levels of growth and accomplishments in the second half of the program. I'll be back with Part 2 at the end of the summer with an updated, completed project!

Additional Readings

Automating Quantifying the Commons: Part 2 | Author: Naisha Sinha | Aug. 2024
Data Science Discovery: Quantifying the Commons | Author: Dun-Ming Huang (Brandon Huang) | Dec. 2022

New CreativeCommons.org launched 2023 September

2024-05-28T00:00:00Z

Creative Commons (CC) launched a new CreativeCommons.org website on 2023 September 27th. This relaunch included not just the website, but the entire technology stack (platform, server, and website components).

Improved platform

The new website is hosted on AWS. This allowed us to design a more secure network architecture between services and deploy/manage the services using infrastructure as code.

Improved services

The services running the website were simplified and updated. The number of distinct servers was reduced from six down to two. Previously, loading the homepage required five services (HAProxy, Varnish, Apache2, PHP+FPM, and MariaDB). The complexity of the old services made troubleshooting more difficult. They were designed before Cloudflare began supporting us through Project Galileo. The new website requires only two services (Apache2 and MariaDB).

Improved website components

Vocabulary

The website consists of a variety of components that use the Vocabulary design system (creativecommons/vocabulary) to present a unified user experience. This relaunch was the first implementation of the new Vocabulary. It has returned to web core principals favoring semantic HTML and appropriately scoped CSS styling. It keeps the style layer responsibilities firmly within the CSS, rather than utilizing a framework like Bootstrap to add a myriad of style-based classes to the HTML layer. Furthermore, JavaScript use has been kept incredibly minimal, offering routes of behavior that can’t already be accomplished via HTML and/or CSS, letting HTML and CSS do what they do best. This simplicity improves performance and also lowers barriers for community contributions.

Accessibility was a priority, making the code more semantic already helps, but we went further in ensuring that all the affordances you get from HTML aren’t blocked or altered via opinionated (and often non-standard) frameworks. The site performs better generally, and is much kinder to slower connection speeds.

The new implementation of Vocabulary includes a new Information Architecture and more stable UX approach for better visitor experiences. CC licensed media is one of our strengths and as such it was important to allow proper attribution to be baked into every instance of media rendering within the design. This means that while the image or video may be important to the flow of content, its attribution also gets a level of appropriate importance as well, highlighting ways in which others might handle attribution and following through on our own mission in the pursuit of better sharing at large.

WordPress

The project utilizes a custom WordPress theme (creativecommons/vocabulary-theme) that implements the new Vocabulary design system.

The theme utilizes the WordPress Classic Editor because of its long-term stability and more stable UX. Gutenberg still does not adhere to adequate Accessibility approaches, nor does it have a sense of stable feature-completeness. This creates an unreliable landscape to build upon. Gutenberg also requires one to build Block composition through React.js to accomplish tasks that are far easier and more approachable with the standard PHP templates that the Classic Editor is compatible with. This dramatically improves the ability for a new contributor to help, and speeds up the development process.

To allow a degree of more varied page composition, Advanced Custom Fields was utilized to more easily add, update, and version control custom fields across pages and page templates. This strikes a balance between more complex page composition, but within a more controllable set of circumstances.

Plugins in general were cut dramatically. The legacy site contained 20 active plugins, while this project relies on less than half, at 9, with hopeful pathways to eventually cut that number even further.

The site utilizes several custom content types and better taxonomies to split up the UX flow of varied kinds of content creation, allowing for smoother multi-author attribution, site-wide notices for fundraising and event announcements, and better blog post organization and way-finding overall.

CC Legal Tools

With the deployment of our new website, we also replaced the legacy ccEngine with the new CC Legal Tools. The current legal tool landscape is refreshingly simple with only seven tools (CC BY 4.0, CC BY-NC 4.0, CC BY-NC-ND 4.0, CC BY-NC-SA 4.0, CC BY-ND 4.0, CC BY-SA 4.0, CC0 1.0). However since previous versions of the licenses were adapted to specific jurisdictions (ported) and we collaborate with the community to support many translations, the new CC Legal Tools app manages over 30,000 documents!

The project to rewrite the CC Legal Tools and replace the legacy ccEngine began in 2020 with a request for proposals (RFP: License Infrastructure - Google Docs). The Caktus Group began the new CC Legal Tools using the Django Python web framework. The work was continued by Timid Robot. Saurabh helped with RDF/XML generation (CC Legal Tools: Machine-Readable Layer — Creative Commons Open Source).

The new CC Legal Tools consist of two repositories:

creativecommons/cc-legal-tools-app: Static site generator using Django
creativecommons/cc-legal-tools-data: Inputs and outputs of the application

The legacy ccEngine consists of around 15,960 lines of Python 2. It was developed and extended organically over time, resulting in a less coherent codebase. The new CC Legal Tools has the benefit of hindsight and was architected as a single application to meet all of current requirements of CC. It consists of around 17,400 lines of Python 3 (including around 4,000 lines of tests). Benefits of the new CC Legal Tools include:

Currently supported software (Python 3, Django 4.2, etc.)
Simplified data model
Improved translation handling
Improved RDF/XML generation/management

In particular, the fact that the new CC Legal Tools generate static assets is noteworthy. Static assets can be hosted performantly with a very simple service setup.

Chooser

The new chooser beta (creativecommons/chooser) was promoted to production with the new header and footer from the Vocabulary design system for a more uniform user experience.

FAQ & Platform Toolkit

The FAQ (creativecommons/faq) and Platform Toolkit (creativecommons/mp) were updated to use the new header and footer from the Vocabulary design system for a more uniform user experience.

Improved development

Utilizing infrastructure as code, we now have a much more robust staging environment. This allows us to preview larger changes so that they can be deployed to production with minimum risk. We also improved our local development environment and content synchronization tooling (creativecommons/index-dev-env). This means that not only did we fix many old bugs, but when new bugs are identified, we can fix them more rapidly!

Thank you

Thank you to the people who directly contributed to the success of the new website!

Nate, former Director of Communications & Community
Sara, Full Stack Engineer
Shafiya, Systems Engineer
Timid Robot, Director of Technology
as well as many other previous staff, community contributors, and other supporters!

CC Legal Tools: Machine-Readable Layer

2023-08-28T00:00:00Z

Greetings, readers!🌟 I'm excited to share that as part of Google Summer of Code (GSoC) 2023, I had the incredible opportunity to contribute to the exciting project "CC Legal Tools: Machine-Readable Layer." This journey has been a remarkable blend of learning, coding, and collaboration, and I'm thrilled to share the highlights of this journey with you all.

Project Overview

The project's core focus was to enhance the Creative Commons (CC) Legal Tools app by introducing a robust machine-readable layer. The machine-readable layer enables computers to understand the intricacies of CC licenses, making it easier for legal professionals, developers, and enthusiasts to work with CC licenses programmatically.

Getting Started

My journey began with delving into the existing codebase and understanding the project's requirements i.e. understanding the app's architecture, its components, and how it currently handled CC licenses was crucial for what lay ahead.

RDF, or Resource Description Framework, emerged as a crucial player in the project. Grasping the intricacies of RDF and its role in representing licenses was a necessary step in the journey.

Challenges and Learning Opportunities

One of my early challenges was unraveling the complexities of the legacy RDF/XML files. How did they differ from the new RDF/XML files we aimed to generate? This exploration led me to discover improvements in structure, updated license information, and additional metadata.

Generating RDF files for various licenses and versions became a puzzle to solve. Crafting RDF triples, understanding licensing nuances, and weaving this logic into the app's views became both a learning opportunity and a rewarding challenge.

Contributions and The Work

As the project evolved, I worked to dynamically generate RDF/XML files, allowing the app to generate machine-readable licenses on-the-fly.

To maintain an organized approach, it is ensured that the generated RDF files are sorted, all the credit goes to Timid Robot.

The newly generated RDF/XML aims to enhance the clarity, accuracy, compatibility, and standardization of Creative Commons license representation in RDF format. These improvements boost machine-readability and semantic understanding, fostering seamless integration and interpretation in digital systems.

Overview of changes:

Improved Structure and Consistency:
- The new RDF/XML boasts a more organized, standardized structure, aligning with RDF standards. This enhances machine comprehension and accurate data processing.
Updated License Information:
- License information has been updated to reflect the latest permissions and restrictions. This ensures users and systems are informed accurately.
Alignment with RDF Best Practices:
- Changes align the representation with RDF best practices. This boosts interoperability and compatibility, thanks to standardized namespaces, consistent naming, and proper relationship definitions.

Throughout the journey, I had the privilege of working closely with my mentor, engaging in collaborative discussions and receiving insightful code reviews..

As my GSoC journey draws to a close, I'm excited about the foundation we've laid for the CC Legal Tools app. The machine-readable layer opens doors to a future of smarter, automated legal processes.

The improvements made during GSoC will continue to ripple through the CC Legal Tools app, benefiting users and the broader open-source community.

Mentor and Support

A heartfelt thanks to my mentor, Timid Robot, for guiding me through this incredible journey. Your unwavering support, wisdom, feedback, and willingness to share knowledge have truly been invaluable. I'm deeply grateful for the opportunity to learn and grow under your mentorship. Thank you for making this journey unforgettable.

Takeaways and Conclusion

GSoC became a platform for me to acquire new skills, dive into complex concepts, and broaden my horizons. The learning experience was immersive and transformative.

Being part of the open-source community was a revelation. Interacting with like-minded individuals, contributing to a shared goal, and experiencing the true essence of collaboration was a highlight.

My GSoC journey has been a remarkable adventure of exploration, discovery, and growth. The project's mission to create a machine-readable layer for CC Legal Tools has left an indelible mark on my journey as a developer.

Thank you for joining me on this expedition. Here's to the future of open-source contributions and the endless possibilities they hold.

Cheers,

Saurabh Kumar

New Chapter of My Professional Life

2023-06-20T00:00:00Z

Greetings, readers! I’m Shafiya Heena, from Hyderabad, India, who now finds herself immersed in the vibrant city of Toronto, Canada. After spending six fruitful years as a DevOps Engineer, I recently embarked on a new professional journey with Creative Commons, a nonprofit organization. Today, I want to share my experiences and thoughts on the stark differences in culture between these two organizations and shed light on my recent encounter with an event called InTown Week (ITW).

Before joining Creative Commons, I had limited exposure to open source initiatives and nonprofit organizations. However, upon stepping foot into Creative Commons, I found myself captivated by its unique culture. The emphasis on collaboration, transparency, and fostering a sense of responsibility among staff members left me awestruck. The organization's commitment to open source and its associated ethos ignited a newfound passion within me.

Prior to ITW, I had heard positive whispers of this event, but had little knowledge about its significance. Little did I know that this week-long gathering would prove to be an enlightening and transformative experience. Over the course of five days, I delved deep into self-discovery, learning more about my team members, and gaining profound insights into Creative Commons as an organization.

One aspect that particularly struck me during ITW was the knowledgeable, sense of equality among staff members. Everyone was encouraged to share their opinions, even if they contradicted the prevailing decisions. This environment fostered a culture of inclusivity and collective growth. Additionally, I had the opportunity to take an insightful discovery test that provided valuable insights into my personality traits and how I could enhance my contributions within the team.

During all the conversations and activities, I found myself occasionally getting lost in the whirlwind of information. Thankfully, I was fortunate to have a dedicated mentor who skillfully guided me back on track, ensuring that I comprehended the nuances of the happenings around me. Through this mentorship, I discovered how to boost my energy levels and become an even better fit within the team.

While the experience of ITW was enriching, it was not without its challenges. Due to visa issues, I was not able to attend in person. Engaging in extended virtual calls throughout the week was demanding, but the active participation from every individual in all activities made it all worthwhile. One particularly heartwarming moment was bidding farewell, as everyone stood in a row to say goodbye to me personally on the screen. This gesture made me feel truly present, transcending the virtual realm, and I express my heartfelt gratitude to my mentor for facilitating such connections.

A notable contrast I observed during my time at Creative Commons was the vivaciousness and approachability of the CEO. In stark contrast to my previous organization, where CEO communication was primarily limited to formal emails announcing changes or decisions, I was pleasantly surprised by the CEO's warmth and genuine interest in engaging with employees in a personable manner. This refreshing leadership style evoked a sense of enthusiasm and bolstered my commitment to the organization's goals.

To encapsulate my thoughts on the open source culture at Creative Commons in a single word, I would choose "likable." My mentor, in particular, played a crucial role in establishing transparency by designing a comprehensive three-month onboarding document, which laid out expectations and goals. Here, although the infrastructure may be smaller, the workflow is streamlined, and there is an absence of restrictive IT teams that hinder access to websites or prioritize hardware security over staff responsibility. Instead, Creative Commons embraces a culture where employees take ownership of their hardware, fostering an environment of trust and empowerment.

Many Mona Lisas? Artistic Data Quantification and Assessment

2023-04-26T00:00:00Z

Quantifying the Commons

University of Michigan, School of Information

Project Objective and Problem Statement

Creative Commons (CC) has over one billion licensed works. However, there is no central data or organization of CC’s licensed works, making it difficult to quantify the number of works and to analyze which licenses are useful or should be retired. The goal of this project is to help CC staff identify redundant licenses and use quantitative data in marketing its impact. It focuses on Open Education Resources (OER).

Data Collection

Data was collected from OER Commons, which is one of CC’s platforms and a library containing digital education resources. The first step in data collection was identifying which licenses this data source uses and how many works are under each license within OER Commons. OER Commons uses the licenses CC-BY, CC-BY-SA, CC-BY-ND, CC-BY-NC, CC-BY-NC-SA, and CC-BY-NC-ND which contribute to both ‘fair use’ and ‘commercial use’ assets, respectively. The next step in data collection was querying the Application Programming Interface (API) by license. In order to retrieve all works for a license, queries are batched by a maximum of 50 works retrieved at once. This process is repeated until all works for a license are retrieved. These steps are run for every license. For every API call, the response is in XML which is parsed for features including education level, subject area, material type, media format, languages, primary user, and educational use. The results are outputted to a tab-separated CSV file.

Exploratory Data Analysis (EDA)

After collecting all of our data, we began exploring the different columns in our dataframe. In particular, we looked at the distribution of different languages, the distribution of items by license type, and when items were added to the OER Commons API. Through this exploration, we were able to further specify our analysis and dig deeper into the different relationships of the data.

Diagram #1:

Diagram #1 shows the distribution of items taken from OER Commons by license type. It is clear that the CC-BY license type is the most popular, with 43% of the items having that license type. The CC-BY-SA license is also fairly popular, accounting for 27% of the items collected.

Diagram #2:

Diagram #2 shows when items have been added to the OER Commons API. There is little activity from December 2015, up to the beginning of 2023. However, close to 30,000 items were added to the API in early 2023.

Diagram #3:

Diagram #3 shows the percentage of items by language. English is the most used language, with about 86% of the items being in English. The other languages each have a small amount of the items.

Diagram #4:

Since English is clearly the most popular language, we decided to see the license distribution for items that are in English. Diagram #4 shows a similar distribution to the pie chart depicting the overall license distribution; this is to be expected since items in English account for 86% of all items, so the distribution of licenses is similar to the overall distribution.

Diagram #5:

We continued to look at the distribution of licenses by each language. Diagram #5 shows that for the items in French, CC-BY license is the most popular at 49%, with CC-BY-SA being right behind it at 32%.

Visualizations

Diagram #6:

Diagram #6 shows the distribution of items on OER commons by primary user and broken down by license type. The platform predominantly contains items designed for teachers and students, with the rest for parents, administrators, librarians among others. The breakdown of licenses for each primary user is relatively consistent with the overall breakdown of the platform, as seen from the charts below (Diagram #7 and Diagram #8).

Diagram #7:

Diagram #8:

Diagram #9:

Another aspect analyzed was inspecting the subject areas and the licenses that they hold as shown in Diagram #9. Some preliminary data cleaning had to be conducted as there were too many subjects on the platform, while some subjects had very low counts. The team grouped similar subjects into nine different categories, for example, social science, anthropology, sociology, communication, world cultures, psychology, women’s studies, and social work were grouped into social sciences.

It can be seen from Diagram #9 that the most popular subject areas on the platform are health sciences, language/arts and other sciences. Diving deeper into these subject areas, health sciences and language/arts have a higher proportion of items with the CC-BY-NC-SA license.

Diagram #10:

Finally, the team analyzed the material types of the items and sorted it by education level that the items were created for. Again, some data cleaning was required as there were too many material types to analyze and some also had very small data counts. The seven material types shown in Diagram #10 were the most popular, and represented roughly 2/3 of the total.

After sorting the education levels in chronological order, an interesting trend that emerged is that the number of items increases with education level from preschool, hits a peak at the community college level, and then decreases afterwards. A shift in the material types can also be drawn from the graph, as lesson plans represent a large proportion of items from preschool to high school, but become insignificant from the college level onwards. On the other hand, this is replaced by a higher proportion of readings. Another observation worth remarking is that there is also a higher proportion of items at the college level for textbooks.

Key Value

The insights created through the analysis of this project will be helpful for CC’s marketing efforts. The ability to understand the distribution of license types in different contexts such as education level, will help CC be better equipped to target their marketing toward key demographics such as preschool education materials for example. Another take away in terms of key value was CC’s initiative to long term preservation. CC’s need to centralize their collaborators' content into a database warehouse system has been an identified direction since the start of this project. Our prototype database of the OER Commons has contributed to these efforts in both small scale implementation as well as meeting the scope of our database system modeling. As other CC cohort chapters contribute their own databases of licenced works, there is a hopeful expectation that a merger of acquisition will take place with other CC chapters in the future.

Next Steps

As CC expands its contributing members into the open-source initiative of bringing licensed works to the world, other internal systems of data preservation and maintenance start to become a point of serious interest as the databases start to become an integrated endeavor in the future. Running our prototype case study of the OER-Commons database has given us insights on the direction of CC current database system and how this system will be better suited to evolve into a data warehouse hub as a long-term solution. When we started the process of data mining and data analysis, using Python3 has been a staple in both our groups efforts as well as CC’s previous protocols with Git. So, complementing this framework with other Python libraries that allow for easier database querying will be a step in the right direction for the next cohort of CC contributors to further this process along. An example of this library integration would be pandasql to utilize the family pandas library methods along with the SQL command logic that makes database maintenance easy and manageable. Besides updating the data storage, future work can continue to collect data from other sources with CC licensed work including the GLAM and Internet Archive.

Acknowledgements

We would like to express our gratitude towards Timid Robot Zehta, our client, for working on behalf of CC, as well as OER Commons for their valuable contributions towards the development of digital licensing and open source databasing initiatives. Without them, this project would not have been possible. Their efforts have been instrumental in giving us the tools and resources to help progress in the open-source initiative by allowing us to promote the free exchange of ideas, knowledge, and resources within the art, health, and education sectors of non-profit endeavors. Open source projects are important because they allow the public to use and work on projects without restrictions or keys. Since this initiative is open source, our efforts can be added to and built upon, allowing the project to continue through the addition of new contributors with fresh perspectives. Both of their commitment to promoting accessible and inclusive content has enabled individuals and organizations to create and distribute digital assets without facing any legal restrictions around the world. It has been an absolute pleasure to work with these organizations and be a part of their mission to democratize access to information.

Considering Community Contributions at Creative Commons

2023-03-24T00:00:00Z

Different open source communities work differently and so everyone may arrive at Creative Commons' projects with their own set of individual expectations. Someone might expect to directly submit a Pull Request to a project without an Issue. Or they may submit an Issue and then immediately an associated Pull Request. At Creative Commons we have a process we hope to follow so there's a chance for consideration, community participation, and discussion along the way. Where we make collaborative, well documented, and informed work more possible!

Things usually begin with an idea for new functionality, new/revised documentation, or an encountered error of sorts. That idea or error is then captured as a GitHub Issue used to describe its details. Think of this as the Abstract that comes before the Implementation.

It's important to first look through all the existing Issues, including ones that have been Closed to determine if someone else has already made an overlapping Issue. If they have, it's best to add any new information you've discovered or thought of as a comment (or series of comments) to that Issue, rather than create a new one.

Errors (often referred to as Bugs) should be verified, and reproducible if possible. Things like screenshots, steps to reproduce, a video, and environment details are all incredibly helpful for others when they want to review the error. All that information is gathered and placed in a succinct, but detailed Issue on the associated repository. It's worth noting that the documented Issue alone is a valued contribution. It will provide guidance and documentation for whomever works on resolving or implementing it, so it's just as important as the eventual code that will be written. That means it should be done well, because the better an Issue describes an error and provides a clear way to reproduce it the easier it will be for anyone to address it.

Functionality and Feature proposals are often a little more involved. Errors are some aberration in the existing expectations or functionality of the codebase's state, but new/changed functionality or features introduce larger planning considerations. They have to take into account the current state of things and the proposed future state they're introducing as an Issue. This is an exercise in communication and description first and foremost, and that means that having a detailed writeup, wireframes, mockups, and evidence to support the proposal is vital to its success. Where Errors might be able to consider a more isolated set of consequences to fixing something, introducing new features/functionality may have unintended side effects, it may require multiple parts of the codebase to be changed or altered. All of these larger picture considerations should be taken into account and addressed within the Issue. One should expect that a Feature Issue may on average take longer to introduce, and longer to adequately document in a clear and concise way to get the point across to the rest of the community.

Documentation can always use improvements whether within code comments, a project's README.md, or associated documentation. These would largely be considered a "Feature Issue" technically but it's worth pointing them out separately because they're as important, if not more so, than fixing errors or adding codebase level functionality. Good documentation makes the project strong and the community more informed. Improvements here should document where there's a gap or where revisions are needed, and how they should be corrected.

Whether an Error or Feature/functionality Issue, once it's been submitted, in accordance with the Contribution Guidelines, it will move to a status of "awaiting triage". This means that it is waiting to be reviewed by one of the core codebase contributors. While it's in this state no implementation work should be done (no PRs, no code work to add or correct the behavior). An Issue submitted is largely the start of a process, and a conversation. Core contributors will review the Issue and see if it adequately describes its appropriate details, and if its objectives fit within the larger pattern and goals of the codebase itself. It's entirely possible that a well thought through Feature Issue that adds some new menu functionality is in isolation a good idea, but that it doesn't fit within the goals of the project in question and won't move forward. And that's OK, even if an Issue doesn't move forward it can now stand as documentation for the community on what won't be worked on at this time, which is just as important as what will. It's a contribution whether it moves forward or not, so long as it describes itself well enough.

If this happens, the Issue will be moved to a status of "discarded", and will be closed with a comment explaining why. The other reason an Issue might be moved to "discarded" is that it duplicates the work in another Issue, which is why it's important to first check all the existing Issues prior to submitting a new one.

Sometimes an Issue might describe something much broader than can be easily contained within itself and may be converted to a status of "discussion". This means that the Issue should spark a larger conversation within the community to consider all the angles of abstract, and possibly split the idea up into more manageable pieces across multiple Issues. Other outcomes might be a discussion that realizes that while the idea is sound, it's not implementable at this time and won't move forward.

Some Issues are solid ideas, but they are not something that can move forward until work on other Issues is completed first. As such they tend to move to a status of "blocked". They'll sit in that state until they're unblocked and the work can happen.

If an Issue seems like it doesn't have enough information to determine what to do with it, then it will likely move to a status of "ticket work required" and a comment will usually be left describing what needs to be worked on.

Remember, an Issue is a form of documentation, and in a way it's a conversation, and that means that until it moves forward it's very much a work in progress.

If an Issue passes through this period as implementable, then it'll move to a status of "ready for work". This is the point at which it can be implemented, and a contributor can submit a Pull Request addressing it. (See the Repository Labels Status section for more information)

During this process it is worth noting that there will be multiple types of contribution. For example:

The Issue itself is a contribution
Comments on the Issue from the community refining it are each contributions
Someone's comment on the Issue helping another person sort out why the Error is occurring is a contribution.
Someone finding another related Issue and linking it as relevant to that Issue is a contribution.

All of these contributions occurred before a Pull Request was ever initiated. Once an Issue enters a status of "ready for work" someone who has indicated interest on that Issue will be assigned to it and can then fork the repository, make a branch to work within, and once settled submit a Pull Request. That process alone may involve several contributions as well, such as:

The code work encounters a problem, someone asks for assistance within their draft PR, and several members offer help as comments.
Someone reviews the final PR and leaves a detailed review on what might need addressing
A discussion breaks out on the best way to resolve an encountered problem with the PR, each of these comments is a contribution
And, of course, the PR itself is a contribution.

If the PR passes Review then it'll be marked as Approved and merged into the codebase, that will trigger the associated Issue to close as complete and now the Error Fix or Functionality in question will be fully implemented into the project.

To get here it took multiple contributions, from different community members, that's the power of open source!

Outreachy Internship Mid-point Progress Update

2023-02-01T00:00:00Z

Outreachy Internship- Refactor CC Meta Search- Mid-point Progress Update

As an intern at Creative Commons, my original project timeline was to refactor the old CC search website to use semantic and modern HTML and CSS. This project was intended to improve the user experience and make the website more accessible to a broader audience. The old CC Meta Searcg website is built on PHP and JavaScript. My major goal for this internship is to convert the PHP to semantic html and modern CSS while ensuring that all neccessary functionalities are intact.

I have met several of my goals in the first half of my internship. So far, I have successfully refactored the website's HTML to use semantic elements, which improves the website's accessibility and makes it easier for users to understand the content. I achieved this by creating a new index.html file and rebuilding the site with semantic HTML. Additionally, I have also implemented modern CSS techniques to improve the website's visual design and make it more responsive on various devices. All of this is currently being reviewed by my mentors for feedback on additional changes that might be needed.

However, there were some project goals that took longer than expected to complete. One of the main reasons for this was that the website's codebase was not well-organized, which made it difficult for me to navigate and understand. Additionally, the site had a pre-determined CSS file that I was supposed to follow or incorporate while building the new site, but this file was so cumbersome and most of the styles did not give the desired result. I spent a lot of time trying to understand and navigate through this and eventually I had to speak to my mentor about it, and also brought up the suggestion of me writing out my own CSS stylings, which she agreed to. Thus this made the original goal, of incorporating the CC Vocabulary CSS file, to be modified.

Additionally, I had to prioritize certain tasks over others and make adjustments to my plan as necessary.

The new CSS I have written so far already makes the website's layout responsive. I have also created a new script.js file and started working on the neccessary functionalities of the website. I plan to implement all feedback gotten from my mentors and debug any remaining issues. Additionally, I will be working on improving the website's overall performance by implementing several optimization techniques as necessary.

Overall, My aim is to ensure that the website is fully functional and user-friendly for all users.

How I Landed My First Internship With Outreachy

2023-01-04T00:00:00Z

Take a moment to resonate with the words above. This is a principle I always follow in life. "Doing it scared"

Get To Know Me

My name is Precious Oritsedere. I am a Nigerian. I am a software engineer who is known for her dedication to her work and her strong core values. I believe in the power of love, contribution, and empathy, hence I use these values as my guide in both my personal and professional life.

As a young girl, I have always been fascinated by technology, gadgets, and even games. However, I didn't study any technology-related courses at university. I graduated with a degree in International Studies and Diplomacy but this didn't stop my curiosity for Technology. I really wanted to pursue my passion for technology but I was unsure of the means to go about it because I had no guide.

Fast-forward to January 2022, I spoke to a friend about how I really wanted to know and learn more about Software Engineering and he introduced me to AltSchool Africa. This was the starting point of my Tech Career. Subsequently, I began to learn all about Frontend Engineering, and I also got introduced to open source.

Why I applied to Outreachy

As a software engineer, I am committed to using my skills to make a positive impact on the world. I believe in the power of collaboration and teamwork and I am always willing to lend a helping hand to my colleagues. This was why the concept of open source really appealed to my personality.

One of the things that motivate me, is my desire to give back to my community. I am passionate about making a difference, and this is why I applied for the Outreachy internship. Outreachy is a program that provides paid internships in open source and open science. Outreachy provides internships to people subject to systemic bias and impacted by underrepresentation in the technology industry where they are living. Interns are paid a stipend of $7,000 for a period of 3 months.

The Outreachy application process consists of three stages: the initial application, the contribution period, and the final application. And I was determined to succeed in each stage and eventually secure an internship. Which I did! Here's how;

The first stage of the application process was the initial application. I carefully reviewed the requirements and made sure I met all of them. We were asked to write 3 essays centered around how we have been underrepresented in the tech industry. I took quite some time to carefully think this through before writing my essays. After which, I submitted my application on time and waited for a response.

A few weeks later, I received an email from the Outreachy organizers stating that I had been selected to move on to the next stage: the contribution period. This stage involved making a contribution to an open-source project. I was excited to have the opportunity to make a real impact and I spent hours researching the different projects. I eventually chose to contribute to the Creative Commons project "Refactor CC Meta Search".

Creative Commons is an American non-profit organization and international network devoted to educational access and expanding the range of creative works available for others to build upon legally and to share. They also help overcome legal obstacles to the sharing of knowledge and creativity to address the world’s most pressing challenges.

I was so determined to make a high-quality contribution to this project. I learnt a lot during this stage. I got introduced to new tools like Docker , Linux and even PHP. I spent countless hours learning the codebase and working on my contribution. In the spirit of love and collaboration, I spent a lot of hours helping my fellow Outreachy applicants who were beginners or confused about what to do. I also reached out to the project mentors for guidance when I got stuck and feedback on the contributions I was making.

My hard work paid off and I successfully submitted my contribution on time. For the final stage, I made a final application to be considered for an internship position with Creative Commons.

I was so thrilled when I received the congratulatory mail some weeks later that I had been selected for the internship. My success in the Outreachy application process was a result of my dedication and hard work. I put in the time and effort to ensure I met all the requirements and made a valuable contribution to the project. And I am happy to announce that my determination and perseverance paid off and I was rewarded with a valuable internship opportunity.

In conclusion, Precious Oritsedere is a talented software engineer who is dedicated to her work and driven by her core values of love, contribution, and empathy. She is motivated by her desire to make a difference, and this is evident in her commitment to her work and her participation in the Outreachy internship.

Thinking More Openly About Working in The Open

2022-12-16T00:00:00Z

I began working at Creative Commons (CC) as the Full Stack Engineer this year and it’s been amazing to get to work in the open at CC. But as someone who has been working in closed, internal source environments for a very long time it’s definitely been a learning experience and a perspective shift.

For years I benefited from, observed, and offered up personal work into the world of open source, but I was never deeply involved in other projects in a big way, nor was I able to contribute anything I did at my professional day job back into the open source world (despite the benefit open source afforded the work I did every day). It had been a hope of mine, something I had advocated for, but had ultimately not worked out. Now at CC I finally get to participate in projects that operate in the open, and a larger community of contributors around the world.

It's been refreshing and rewarding, but it's also been enlightening. There's so much that's different now. Working in the open doesn't just shift the terms under which your code is licensed or how many people can contribute, it requires a significant shift in both approach and process.

For example, working in the open means that while there may be community members eager to contribute they may lack contextual understanding that someone more intimately familiar with a project might develop over time and rely upon. To support contributions well you need to have a heavily documentation-first strategy that affords new contributors key information in understandable and clear instructions.

That also means that documenting issues isn't just an item on a todo list you'll get to later. There's extreme value in writing out detailed information both for your future self, but also for any would-be community contributors to understand the problem and address it. Setup instructions, contextual documentation about the codebase, as well as detailed known issues, roadmaps, etc. All of it needs to be documented and written out, which not only benefits the community contributors, but also benefits the project as a whole. It means key information has to live in the open alongside the code it informs. It's truly a win-win all around.

The process also has to shift, you can't just make a list of things you want to tackle and get to work, you have to consider how each item can be smoothly adopted as granular and iterative Pull Requests that might all be worked on by entirely different individuals. The level of care in how the work is divided and scoped matters even more in this situation than it would have with an internal team. Working in the open doesn't just mean coding in the open, it also means planning in the open, and that means having a clearer view on the overall roadmap and goals the project hopes to meet.

If you are the steward of a codebase any task list you create or issues you identify are ultimately not just for you alone. Putting an item on your list when you're working alone isn't enough, you've also got to find time to work on that item, and work your way through completing it.

In the open source context, working with a community of contributors, creating an issue is just as important and meaningful as writing code, in many cases it might actually be MORE important. Because issues are often the way in which contributors first offer up help and insight, they're the first contact they have with your project. Furthermore, any issue you create may end up getting completed by one or more people that are not you, which means it doesn't just sit on a list till you do it. It's a small, but significant shift in how you think about planning and breaking down work on a codebase in the open.

It’s certainly new, but incredibly rewarding. Even on days where I might not get to submit a Pull Request myself, or squash a bug in a meaningful way, I can still feel I offered up meaningful contributions to the community and the codebase through better documentation, answering someone’s question, reworking a process, or reviewing someone else’s generous contribution. Open Source means opening up your definition of what contribution means, and it’s a lot broader and more meaningful than I thought.

Data Science Discovery: Quantifying the Commons

2022-12-07T00:00:00Z

University of California, Berkeley, Data Science Discovery Program Fall 2022

Project Objective

Problem Statement

In the previous years, from 2014 to 2017, Creative Commons (CC) have been releasing public reports detailing the growth, size, and usage of Creative Commons, demonstrating the significance and influences of Creative Commons. However, the effort to quantity Creative Commons has ceased at the proceeding year. This is the preincarnation of our current open-source project: Quantifying the Commons.

An example visualization from the previous report in 2017:

The reason is that prior efforts to generate usage reports suffered unreliable data retrieval methods; while prone to malfunction over the updates of website architecture from data sources, these data extraction methods are not particularly rigorous in performance and have a significantly low (compared to current methods, at the scale or an hour v.s. 5 business days).

To advance and continue the work of quantifying CC product states, the student researchers are delegated the design and implementation for reliable data retrieval processes on CC data that were employed in previous reports to replicate past efforts of this project's preincarnation, quantify the size and diversity of CC Product Usage on the Internet.

Data Retrieval

How to detect county of CC-Licensed Documents?

If an online document uses a CC tool to protect it, then it will either be labeled as license under that tool or contain a hyperlink towards a creativecommons.org webpage that explains the license's rules (the deed).

Therefore, we may use the following approach to identify and count CC-licensed documents:

Select a list of CC tools to inspect (provided by CC).
Use APIs of different online platforms to detect and count documents that are labeled as license by platform and/or contains a hyperlink towards CC license webpages.
Store these data in tabular form to contain the count of documents protected under each type of CC tools.

What platforms to collect counts from?

Here is a list of online platforms that we sampled document count from, as well as the delegations for platforms' data collection, visualization, and modeling in this project:

Platforms Containing Webpages	Platforms Containing Photos	Platforms containing Videos
Google (Dun-Ming Huang)	DeviantArt (Dun-Ming Huang)	Vimeo (Dun-Ming Huang)
Internet Archive (Dun-Ming Huang)	Flickr (Shuran Yang)	YouTube (Dun-Ming Huang)
	MetMuseum (Dun-Ming Huang)
	WikiCommons (Dun-Ming Huang)

Exploratory Data Analysis (EDA)

Here are some significant defects found in datasets across sampled platforms during EDA:

Flickr

Sampled Document Count from this dataset is at 35,000% ~ 100,000% of deviation from official statistics per CC product (license) investigated.
Sampling frame locked at 4,000 available searched photos from each license.
Significant duplication issue (resolved).

Google Custom Search API

Programmable Search Engine only reaches a subset of Google's website. The impact is not significant (then, further resolved via sampling frame adjustments in PSE).
Accidentally used deprecated operators and parameters, causing faithfulness problems (resolved).

YouTube Data API

API has maximum response value on total count of YouTube videos, causing severe underestimate.
- Resolved via implementing custom granularity on data to enable honest response, conserve development cost, and introduce imputations in visualization.

Expanding the Dataset

Here are reasons and efforts of dataset expansion on platforms that received more data:

Google Custom Search API

Revised Data Sampling process to solve EDA-discovered inaccuracies.
For expanding the horizons of CC product usage analyses upon past boundaries, where visualization was only conducted to compare cross-product performance, I incorporated further CC-product usage data across temporal axis and geographical demographics.

YouTube Data API

Revised Data Sampling process to solve EDA-discovered inaccuracies.
To perform unprecedented analyses on media-specific time-respective developments of CC options on popular platforms, YouTube's CC-licensed video count across two-month periods.
Introduced imputation to alleviate unresolvable capped responses from YouTube and mitigate developmental cost in response to Youtube API's capping behaviour.

Visualization

Philosophies and Principles

The visualizations of Quantifying the Commons is to be communicative and exhibitory.

Some new aesthetics and principles we adopted (as a response to enhancement of prior efforts) are to:

Present length in place of area for comprehensibility
Analyze product development beyond license-wise comparisons
Utilize colors for presenting data inclinations via works in Pandas, Seaborn, NumPy, Geopandas, and SpaCy

Exhibiting a Selection of Visualizations

Diagram 1C

Trend Chart of Creative Commons Usage on Google

There are now more than 2.7 Billion webpages protected by Creative Commons indexed by Google!

Diagram 2

Heatmap on density of CC-licensed Google indexed webpages over country

Particularly, Western Europe and Americas enjoy a much robust use of Creative Commons document in terms of quantity. A Development in Asia and Africa should be encouraged.

Diagram 3C

Barplot for number of webpages protected by six primary CC licenses

We can see that Attribution (BY) and Attribution-Nonderivative (BY-ND) are popular licenses among the 3 billion documents sampled across the dataset.

Diagram 6

Barplot of CC-licensed documents across Free Culture and Non Free Culture licenses

Roughly 45.3% of the documents under CC protection are covered by Free Culture legal tools.

Flickr Diagrams

Usage of CC licenses on Flickr concentrated on Australia, Brazil, United Stated of America while is pretty low in Asia countries.

Note: Sampling Frame of these visualizations are locked at the first 4,000 search results on photos under each general license types.

Diagram 7A

Analysis of Creative Commons Usage on Flickr

Diagram 7B

Photos on Flickr under Attribution-NonCommercial-NoDerivs (BY-NC-ND) license has gained highest possible views, while usage of license Public Domain Mark has highest increasing trend in recent years.

Diagram 7C

Diagram 7D

Diagram 8

Number of works under Creative Commons Tools across Platforms

DeviantArt presents the most number of works under Creative Commons licenses and tools, followed by Wikipedia and WikiCommons. The estimate of video counts on YouTube is understimated, as demonstrated in Diagram 11B.

Diagram 9B

Barplot of Creative Commons Protected Documents across Countries

Diagram 10

Barplot of Creative Commons Protected Documents across languages

Diagram 11B

Trend Chart of Cumulative Count of CC-Licensed YouTube Videos across Each Two-Months

The orange line stand for the imputed value of new CC-Licensed YouTube video counts based on linear regression, which is the decided method of imputation because most medias' growth of CC-licensed document count also experience a linear growth.

Modeling

(A side track)

Objectives of Modeling

The models of this project aim to answer: "What is the license typing of a webpage/web document given its content?"

Individual researchers have attempted each of their solutions via different resources, metrics, under different modeling contexts:

Model of Google Webpages (Dun-Ming Huang)

Modeling Context: Multiclass Classifier (7 classes).
Modeling Training set: Text webpage contents acquired from Google API collected webpages (Common Crawl, the original choice, was marked unavailable due to source code corruption).
Main Model Metric: Top-k accuracy, as this model is considered as the backend of a license recommendation system that receives webpage content and recommend 2 to 3 licenses to the user.

Model for Flickr Photos (Shuran Yang)

Modeling Context: Binary Classifier (BY vs. BY-SA)
Modeling Training set: Text photo descriptions acquired from Flickr API (with sampling frame of visualizations)
Main Model Metric: Accuracy

Training Process Summary: Google Model

Preprocessing Pipeline

Deduplication
Remove Non-English Characters
URL, [^\w\s], Stopword Removal
Remove Non-English Words
Remove Short Words, Short Contents
TF-IDF + SVD
SMOTE

Model Selection

Logistic Regression(
    penalty="l2",
    solver="liblinear",
    class_weight="balanced",
    C=0.1,
)

SVC(
    C=0.5,
    probability=True,
    kernel="poly",
    degreee=1,
    class_weight="balanced",
)

RandomClassifier(
    class_weight="balanced_subsample",
    n_estimators=100,
    random_state=1,
)

GradientBoostingClassifier(
    n_estimators=5,
    random_state=1,
)

NultinomialNB(
    fit_prior=True,
    alpha=10,
)

text : InputLayer
preprocessing : KerasLayer
BERT_encoder : KerasLayer
dropout : Dropout
classifier : Dense

Training Results

Training Process Summary: Flickr Model

Preprocessing Pipeline

Deduplication
Translation
Stopword Removal, Lemmatization
TF-IDF

Model Selection

SVC(
    C=1.0,
    kernel="linear",
    gamma="auto",
)

Training Results

An accuracy of 66.87% was reached.

Next Steps

From Preincarnation to Present

Via the efforts addressed above, we have not only managed to transform a data retrieval process from unstable, unexplored, and unavailable into an algorithmic, deterministic process reliable, documented, and interpretable! And the visualizations have become more exhibitory, concentrating on more effortfully extracted insights, and look at Creative Commons in further depth and more remarkable breadth.

With significant re-implementations and designing policies to the data retrieval process for Quantifying the Commons, visualizations can be readily, immediately produced upon command; and upon the conceptual transformations of visualization production, Creative Commons will obtain new insights into the development of product and eventual policies upon the axes along which data was extracted from. Furthermore, we expect the production of model to work beyond the bounds of a Machine Learning product, but as a possibility to draw inferences upon product usage upon.

Such efforts are a short jump start to the long-term reincarnation of Quantifying the Commons.

From Reincarnation onto Baton Touches

The current team would encourage the future team to increase the availability and user experience for our open source data extraction method, via automation and by-batch data extraction methods, for which Dun-Ming has written a design policy for. For modeling, the team also encourage building ingerence pipelines for using ELI5 for Logistic Regression models, as well as experiment more with loss function options of Gradient Boosting Classifier. For Flickr, the writer of this poster would like to suggest some data extraction method outside Flickr API but has access towards Flickr media, say Google Custom Search API.

Additional Reading

CalVer to SemVer

2022-11-11T00:00:00Z

Creative Commons (CC) tried to use CalVer (calendar versioning), but encountered too many issues and decided on SemVer (semantic versioning) instead.

Why we chose CalVer

Years ago, the CC technology team standardized on using CalVer as our versioning scheme. Specifically, we selected YYYY.0M.MICRO. CalVer:

YYYY - Full year - 2006, 2016, 2106

0M - Zero-padded month - 01, 02 ... 11, 12

Micro - The third and usually final number in the version. Sometimes referred to as the "patch" segment.

The use of CalVer was inspired by Ubuntu, pip, SaltStack, and others. It was thought that CalVer not only matched SemVer in communicating potential risks to users, but also gave additional temporal context. Also, many argue that the promises of SemVer’s MAJOR.MINOR.PATCH go unfulfilled often enough that they lose meaning and that the differences between MINOR/PATCH are too poorly defined (more on these later).

Issues Encountered with CalVer

Time/Duration Is Not Primarily Relevant

CalVer is often favored by projects for which time/duration is of primary relevance (ex. Ubuntu releases which have a limited support window). However, none of CC’s projects have time/duration as a primary relevance.

`MAJOR` Expectations and Slow Iteration

SemVer is a formalization of longstanding convention. Many many users, especially developers, expect the first number of a versioning scheme to indicate change severity. With YYYY indicating current release year, the YYYY.0M.MICRO versioning scheme might set an expectation of significant changes or improvements (ex. 2021.09.1 to 2022.02.1) even when the content of the changes are trivial. With YYYY indicating original release year, a slow moving but stable and functional release might appear abandoned or insecure (ex. 2019.03.2 in 2022).

Poor Support for CalVer

We also encountered poor support for CalVer in software and systems. For example, NPM currently strips leading zeros which breaks CDN integration (CalVer and CDN compatibility · Issue #588 · creativecommons/vocabulary).

Using SemVer

Our experiment with CalVer is a win for the scientific method. We can be more confident, today, that SemVer will treat both the developers and users of CC software better than CalVer.

SemVer’s Promises Commitments

The CC Technology team sees SemVer as a set of commitments we are making to the users and developers of CC open source software. We may not achieve perfection in fulfilling those commitments, but they outline expectations and we hope you’ll open an issue if we make a mistake.

CC SemVer Specifics

We will be using SemVer (semantic versioning) going forward. To add additional clarity, we will avoid mixing functionality changes and bug fixes in releases:

MAJOR version when you make incompatible API changes
MINOR version when you add functionality in a backwards compatible manner
- Releases that increment the MINOR version must not include bug fixes
PATCH version when you make backwards compatible bug fixes
- Releases that increment the PATCH version must not include functionality additions

When a bug fix technically changes functionality, we will release a bug fix (incrementing only the PATCH version) as the change preserves the intended functionality.

Building the CC Global Components Library

2022-03-17T00:00:00Z

Introduction

During the course of my Outreachy internship with the Creative Commons, I got to work on some cool projects, one of which is the CC Global Components library supervised by my mentor Brylie Christopher Oxley.

Having a unified design theme/look or experience accross the different CC websites has always been an important factor while developing these websites. With this in mind, there are several components which are part of most CC web properties. The three components in particular are:-

The Global navigation menu : displayed on sub-paths of the main creativecommons.org website, such as /licenses
The Global footer : displayed on most Creative Commons properties
The Explore CC component : displayed on all CC web properties, such as Global Summit etc.

Instead of having each project implement these components leading to code duplication accross projects and maintenance issues, we decided it was preferable to have a seperate library of these components which finally led to the CC Global Components project.

Choosing a technology

The goal of the Global components library was to build a custom web component that can be served via CDN. While planning, we needed to decide on the technology to use. Agreeably, most web frameworks like React and Vue can be used to develop this but we wanted a simple implementation with fewer dependencies. Some ideal characteristics of what we were looking for was a technology that meets the following criteria:

Web Standards oriented
Clean separation of HTML, CSS, and JavaScript (structure, aesthetics, and functionality)
Lightweight / small bundle size
Loosely coupled (no tight or unrelated dependencies)

The two primary technologies we were considering were Vue JS and Lightning Web Components but finally decided to use Vue JS since we already had other projects developed in Vue (such as the Chooser project).

Building the components

To scaffold the project, we used Vue SFC rollup, which is a CLI templating utility that scaffolds a minimal setup for compiling a library of multiple Vue SFCs (Single File Components) - into a form ready to share via npm. With this, we could just focus on building the templates. We used Vocabulary CSS, our own CC design package to style the components.

The CC Global Footer component was the easiest given that it's mostly static HTML. This component takes two attributes:

logo-url: which should point to the logo of the website it is used on.
donation-url: which is used for the donation button.

After importing the CDN script for the CC Global components, we can then use the CC Global footer in any page as such:

<cc-global-footer
  donation-url="http://example.com"
  logo-url="/example/logo-white.png"
/>

and this renders as shown below:

2) CC Explore

The CC Explore component is an expandable banner which coontains links to all the CC Web properties. This component use a click listener which just toggles the expandable banner to show or hide when it is clicked. As with the CC Global Footer component, the CC Explore component takes two attributes.

<cc-explore
  donation-url="http://example.com"
  logo-url="/example/logo-white.png"
/>

and this renders as shown below:

The CC Global Header was an important component given that we had to make API calls to be able to render the Menu items for downstream projects such as the Licenses and Tools. We used the Axios library for the API calls to the Wordpress backend of the parent project Projec_creativecommons.org.

The CC Global Header has three required attributes, base-url, donation-url and logo-url, which are the URLs used for the API call, Donation button and Logo respectively. There is one additional attribute use-menu-placeholders you can set which renders placeholder Menu Items if you are in a development environment. However, for a stagin/production setup we do not use this attribute.

<cc-global-header
  base-url="http://127.0.0.1:8000"
  donation-url="http:/example.com"
  use-menu-placeholders
  logo-url="/example/logo-black.png"
/>

and this renders as shown:

Conclusion

The first version of this library (0.1.1) was released and published to NPM on Dec 10, 2021. Till date [the time of this writing] we have had several changes and optimizations to the code and are currently on version 0.5.0. This was a really enriching experience for me as it was my first time working with Vue JS. We've also had additional code review and optimizations from Timid Robot.

The CC Global Components with all 3 components used renders as:

You can find the CC Global Components project at:

GitHub: CC Global Components
NPM: cc-global-components

CC Messaging Update 2022Q1 (Dropping IRC)

2022-01-06T00:00:00Z

Past: Moved to Slack

In 2016, Creative Commons (CC) moved to Slack as our primary messaging platform (We're on Slack! Join us! - Creative Commons). We are very thankful for the generous support that Slack has provided. The Slack messaging platform is far more accessible than IRC. We saw an immediate and sustained increase in our messaging community (A month of Slack: Growing global communities every day - Creative Commons, Lessons learned from a year of Slack, 1000 members, and immeasurable community growth - Creative Commons). We currently have 10,293 members in our Slack workspace. Of those, we see daily activity from an average of 250 of them spread across almost 70 public channels. The Slack platform is not without valid criticisms, but those will be addressed in the Future: Open Source section, below.

Present: Dropping IRC

When CC moved to Slack, we also set up a bridge with our three IRC channels on Freenode. However those channels only see ones of active users and tens of messages per year. With the hostile takeover of Freenode in 2021, the Free/Libre and Open Source (FOSS) community has largely moved to libera.chat. However, we will not be moving our Slack/IRC bridge there. Effective 2022-01-24 we are dropping IRC as an officially supported messaging platform. In addition to there having been very few active users on IRC, many of the active IRC users also have active Slack accounts. Dropping IRC will allow us to better allocate our technical resources to better serve the community as a whole.

Future: Open Source

Over the years, Slack has had performance and UX issues. It is also designed around assumptions that do not fit a large open community. Those issues have not prevented it from being a strong and capable messaging platform that has served our community well. However, an Open Source messaging platform would better align with the Creative Commons community and the values we champion. The Open Source and Open Content communities have long enjoyed a significant overlap and collaboration. With regards to messaging, we hope to increase that overlap in the next year or two.

Upcoming Changes to the CC Open Source Community

2020-12-07T00:00:00Z

Creative Commons (CC) is adopting a brand new organizational strategy in 2021, just in time for our 20th anniversary. As part of the organization's evolution in alignment with the new strategy, Alden Page, Brent Moran, Hugo Solar, and I (Kriti Godey) will have departed Creative Commons by the end of December. Moving forward, the CC staff engineering team of Timid Robot Zehta and Zack Krida will focus on supporting a smaller set of core projects.

We are extremely proud of the work we have done together to build CC's vibrant open source community over the past two years. And of course, we're thankful for all the amazing contributions that all our community members have made. We've made significant improvements to existing tools, and launched entirely new projects with your help. We created Vocabulary, a design system for Creative Commons and launched half a dozen sites using it. We added dozens of new sources to CC Search and improved its accessibility. We released tools such as the CC WordPress plugin and CC Search browser extension that integrated CC licensing with widely used software. And, there's so much more.

Community Changes

The CC Open Source community remains central to our engineering work, and we will continue to support you in every way we can. However, based on the new staff capacity, we will be making a few changes to our community processes:

Community Team members will no longer have access to CC's Asana. Most tasks are tracked on GitHub, and managing Asana adds unnecessary complexity to the community team.
We will invite all Community Team members to meetings and documents open to the community, regardless of role.
We will deprecate the "community-team-core" mailing list in favor of a single "community-team" mailing list.
We will have a new monthly Open Source Community meeting and cancel the existing biweekly Engineering Meeting.
We will no longer have a paid Open Source Community Coordinator, relying instead on volunteers to help assist new community members, maintain our Twitter account, etc.

We welcome new Community Team members and we will continue to participate in internship programs such as Google Summer of Code.

Project Changes

With a smaller engineering team, we will need to support fewer projects. Please see below for the current status of all projects with at least one Community Team member.

Active Development

We will continue to actively develop the following projects:

CC Search Browser Extension (maintainer: Mayank Nader)
CC Open Source website (maintainers: Zack Krida & Timid Robot Zehta)
CC WordPress base & child themes (new maintainer: Zack Krida)
CC Legal Database (maintainer: Timid Robot Zehta)
CC Chooser (maintainer: Zack Krida)
CC Link Checker (maintainer: Timid Robot Zehta)
License Buttons (maintainer: Timid Robot Zehta)
Platform Toolkit (maintainer: Timid Robot Zehta)
Vocabulary (maintainers: Zack Krida & Dhruv Bhanushali)
WordPress Plugin (new maintainer: Zack Krida)

Maintenance Mode

The following projects are entering maintenance mode. The services will remain online, but we will not accept any new pull requests or deploy new code after Dec 15, 2020.

Catalog, API, and Linked Commons contributors are encouraged to contribute to our other Python projects such as the CC Legal Database or the upcoming CC Licenses project. If you are a CC Search contributor, we recommend checking out frontend projects such as the CC Chooser or Vocabulary.

Thank You!

We cannot express our gratitude for our community enough. You are all an absolute pleasure to work with, and we're looking forward to continuing to collaborate with you for years to come.

Vocabulary Landing Page & Usage Guide Final Report

2020-12-03T00:00:00Z

We have reached the end of this wonderful journey. Let's comprehensively recap all my contributions during the GSoD internship period!

Vocabulary Site Updates (Edition 4/4)

After securing acceptance, I received the necessary github invites. I was given write access to the Vocabulary GitHub repository as a CC Vocabulary Core Committer.

Proposed Initial Plan

Project Synopsis

Vocabulary has immense potential to be used as a primary UI component library for website building. What it needs is a robust yet layman-friendly how-to guide. Important developer information such as component guides, usage specifications and configuration tweaks form an essential part of any documentation. This will not only encourage existing users to get a feel of how vocabulary continues to grow and reach new milestones, but also promote the usage of Vocabulary in comparatively newer projects. The desired outcomes of my stint as an intern would not only involve penning out a no-nonsense guide to using the pre-existing components but also the designing and developing of a home page (leading to an integrated documentation for each) for Vocabulary, Vue-Vocabulary and Fonts.

Proposed & Improvised Timelines & Deliverables

Here's a list of all the weekly goals that I met:

Pre-Internship

Understood Creative Commons as an organisation, its work and related ethics.
Had a look at CC’s github repositories and understand the code structure.
Opened Issues and PR’s to get acquainted with the repository workflows.
Interacted with my mentor and established the basic ideas regarding the project in question.
Further researched about the needs of the project, and ponder over its potential impact after implementation.

Week 1 (09/14 - 09/21)

Understood Vocabulary, Vue-Vocabulary and Fonts in greater depth, and their existing components.
Designed a first look unified landing page for Vocabulary, Vue-Vocabulary and Fonts based on Vocabulary components.
Interacted with my mentor and other team members and established a rapport.

Week 2 (09/22 - 09/28)

Tackled queries regarding the choice of design, page structure etc., and sought approval from CC’s UX Designer.
Began to write the content which will need to fill up the main landing page.

Week 3 (09/29 - 10/06)

Finalized the headings, sub-headings and other sections which will need to be present in the landing site & documentation.
Kept the code ready for accepting documentation contents. Have github pages/netlify/surge configured for continuous integration and deployment.

Week 4 (10/07 - 10/14)

Began to write under “Introduction”, “Getting Started” and ”Grid Components” sub-headings of the documentation.
Started developing the main landing page using Vocabulary components.

Week 5 (10/15 - 10/22)

Got complete approval for the main page contents.
Worked on coding the “Dark Theme”.
Facilitated hacktoberfest contributors and spoke at a CCOS event.

Week 6 (10/23 - 10/30)

Wrote a mid-internship blog post describing work done and how the experience has been so far with CC.
Started compiling the document guides for all the components in Vocabulary. Made revamps where necessary.

Week 7 (10/31 - 11/07)

Integrated the main page contents and the main landing page itself, had it up and running.

Week 8 (11/08 - 11/15)

Finished writing the Vocabulary usage guide and seek initial approval.

Week 9 (11/16 - 11/23)

Finalized on the guides and the main page contents.
Carried out the necessary landing page to doc integration.
Published a sample build using surge for viewing and surveying purposes.

Week 10 (11/24 - 11/30)

Surveyed development builds for Accessibility using WAVE and Accessibility Insights for Web.
Surveyed the site for responsiveness using Chrome Dev Tools.
Generated Lighthouse reports.
Optimised for Search Engines using meta tags and external links.

Week 11 (11/30 - 12/05)

Worked towards improving the report statistics until they reach a respectable target.
Wrote a blog post summarizing everything, and about my performance cum involvement in CC.

Week 12 (12/06 - 12/12)

Sought daily approvals until everything is finalised.
Go through my writings and code upteen times for any miniscule errors.

Week 13 (12/13 - 12/19)

Cleaned code, make sure everything is properly linted and ready before the final closing commits.
Published the “Concluding Internship” blog post, rounding up my wholesome journey.
Sought final closing approval.

Post-Internship

Promote the use of CC attributed works.
Interact with the community, answer queries or doubts regarding CC.
Carry out community work of the repositories I’ve contributed to.
Leverage experience gained during this internship for future endeavours.

The Vocabulary Site

Here's the link to the landing site.

Went through 3 Design Iterations.
Designed the mockups in Figma.
Wrote the content filling up the landing page.
After approval from the UX Designer, waited for an approval from the Frontend Engineer.
Sought continuous approval from my mentor dhruvkb.
Used Vue.js + CC Vocabulary to build a highly modularised site.
Went through a couple of iterations of the website itself.
Made about 112 commits (15,000 lines of code) in my gsod-nimish branch.




All my contributions to Creative Commons!

Used Github API to display repository statistics.




Fetching dynamic stats from the GitHub API

PR was reviewed and merged on the 25th of November.

Here's how the site looks right now:




Snapshot of the final website!

Used surge & firebase for draft deploys.
Carried out lighthouse testing.




Lighthouse reports for our live site

Prompted changes to improve accessibility, SEO and PWA characteristics.

Core Documentation

Here's the link to the documentation site.

Used StorybookJS.
Modified the existing overview page.
Removed highly verbose sections from the docs.
Documented Vocabulary sprint planning workflow.
Documented how to use a markdown component with CC Vocabulary.
Embedded hyperlink to other open source projects to improve SEO.
Increased uniformity across documentation present in the storybooks.
Added alt descriptions & aria labels for certain images to improve accessibility.

My Learnings And Challenges

Design is more than just picking colors and placing components on a grey screen.
It's important to read your own writings from an unbiased perspective to actually understand how well it would be perceived.
Publishing to npmjs is not difficult!
Knowing the previously existing code in your project is of serious essence. It's important to understand the code styles, structure & activity of the code that you are dealing with.
Be patient! Its fine to delay something if it makes sense to have it logically accomplished only after certain other tasks are done & dusted with.
How essential it is to write neat code is something that's not spoken too often. (I wonder why...)
I always thought Vue.js sets up SPA's by default. I'm surprised you need to configure it additionally to do just that!
Storybook is just a really nifty OSS with great community support!
Vue.js is fantastic. Maybe I'm a Vue.js fan now. Should I remain loyal to React? I don't know.
Making a site responsive isn't the easiest of tasks, but it's certainly doable after a lot of stretching & compressing; lets say that.
"Code formatting is essential" would be an understatement to make.
Monorepo's have their own pro's and con's. But in our case the con's were negligible, thankfully!
GSoD isn't just about documentation; there's some serious amount of coding too!
You don't have to sit and write code for hours together. Take breaks, come back, and the fix will strike you sooner than ever.
Timelines change; improvisation being an essential aspect of any project!
MDX is a neat little format to code in! Documenting code is just so much easier.
Things become obsolete. Versions become outdated. Code maintaining is therefore, easier said than done!

Issues & PR's raised during GSoD period

Repository	Contribution	Relevant links
@creativecommons/vocabulary	Developed the CC Vocabulary Landing Page	https://github.com/cc-archive/vocabulary-legacy/pull/747 https://cc-vocab-draft.web.app
	Implemented dark mode for our storybooks	https://github.com/cc-archive/vocabulary-legacy/pull/806 https://cc-vocabulary.netlify.app
	Carried out a monorepo wide documentation revamp	https://github.com/cc-archive/vocabulary-legacy/pull/813
	Wrote the Monorepo Documentation Story	https://github.com/cc-archive/vocabulary-legacy/pull/785 https://cc-vocabulary.netlify.app/?path=/docs/vocabulary-structure--page#why-is-vocabulary-a-monorepo
	Wrote the Grid Documentation Story	https://github.com/cc-archive/vocabulary-legacy/pull/802 https://cc-vocabulary.netlify.app/?path=/docs/layouts-grid--fullhd#grid-system
	Wrote the "Getting Started" Usage Guide	https://github.com/cc-archive/vocabulary-legacy/pull/774 https://cc-vocabulary.netlify.app/?path=/story/vocabulary-getting-started--page#getting-started
	Added a CHANGELOG.md to adhere to OSS conventions	https://github.com/cc-archive/vocabulary-legacy/pull/671 https://github.com/cc-archive/vocabulary-legacy/blob/main/CHANGELOG.md
	Unified README.md and updated monorepo build process	https://github.com/cc-archive/vocabulary-legacy/pull/649 https://www.npmjs.com/package/@creativecommons/vocabulary https://www.npmjs.com/package/@creativecommons/fonts https://www.npmjs.com/package/@creativecommons/vue-vocabulary
	Configured GitHub native dependabot	https://github.com/cc-archive/vocabulary-legacy/pull/452
	Added phone screen backgrounds	https://github.com/cc-archive/vocabulary-legacy/pull/445
	Introduce Snapshot Testing to Vocabulary using Chromatic	https://github.com/cc-archive/vocabulary-legacy/issues/735
	Add a maintained with Lerna badge	https://github.com/cc-archive/vocabulary-legacy/issues/807 https://github.com/cc-archive/vocabulary-legacy/blob/main/README.md
	Add new install size badges for our packages	https://github.com/cc-archive/vocabulary-legacy/issues/776 https://github.com/cc-archive/vocabulary-legacy/blob/main/README.md
	Customise individual README's for our packages	https://github.com/cc-archive/vocabulary-legacy/issues/736
@creativecommons/ccos-website-source	Introductory First Blog Post	https://github.com/creativecommons/ccos-website-source/pull/530 /blog/entries/cc-vocabulary-docs-intro/
	Vocabulary Site Update v1	https://github.com/creativecommons/ccos-website-source/pull/549 /blog/entries/cc-vocabulary-docs-updates-1/
	Vocabulary Mid Internship Update v2	https://github.com/creativecommons/ccos-website-source/pull/555 /blog/entries/cc-vocabulary-docs-updates-2/
	Vocabulary Site Update v3	https://github.com/creativecommons/ccos-website-source/pull/561 /blog/entries/cc-vocabulary-docs-updates-3/
	Vocabulary Site Final Update	https://github.com/creativecommons/ccos-website-source/pull/564 /blog/entries/cc-vocabulary-docs-updates-closing/
@cc-archive/cccatalog-api	Configured GitHub native dependabot	https://github.com/cc-archive/cccatalog-api/pull/53
@creativecommons/ccos-scripts	Fix file extension in README.md docs	https://github.com/creativecommons/ccos-scripts/pull/100

Follow along my complete GSoD journey through these series of posts.

Memorable Milestones Screenshots




GSoD PR merged!




Behold the dark theme!




Grid Documenation Story




Monorepo Structure Story

Conclusion

My GSoD internship has been by far, a very successful and a fruitful one. I thank the the GSoD team for all their efforts in oragnising it this year. I would also like to thank the entire Creative Commons team for all their motivation and support. The onboarding & see-off was very smooth indeed!

Thank you for all your time! This was the final blog post under the Vocabulary docs series. I'll be around for times to come, but until then, sayonara!

Summary: My GSoD 2020 Journey

2020-12-02T00:00:00Z

Thank you for the wonderful experience, Creative Commons!

This blog post serves as a project report for ‘Improve CC Catalog API Usage Guide’. It describes the work that I’ve done during my Google Season Of Docs (GSOD) 2020. My mentors for this project are Alden Page and Kriti Godey from Creative Commons.

In total, there are 12 weeks in the Doc Development Phase. Every 2 weeks, I would publish a blog post to update my progress to my mentors and organization.

Week 1

So, the first two weeks of Google Season of Docs have passed. For the first week, I added examples to perform the query using curl command. I hit some problem with a Forbidden error. Turns out my access key got expired. My problem was solved after obtaining a new access key.

Week 2

For the second week, I started to write response samples. It was tough as I have a hard time understanding drf-yasg, which is an automatic Swagger generator. It can produce Swagger / OpenAPI 2.0 specifications from a Django Rest Framework API. I tried to find as many examples as I could to increase my understanding. Funny, but it took me awhile to realise that drf-yasg is not made up of random letters. The DRF part stands for Django Rest Framework while YASG stands for Yet Another Swagger Generator.

Week 3

Week 3 was quite hectic. I moved back to my hometown during week 3. Took 3 days off to settle my stuff and set up a workspace. I worked on my GSoD project for only 2 days, Monday and Tuesday. I managed to create response samples for most API endpoints. Had a monthly video call with Kriti this week.

Week 4

I reviewed what I’ve done and what I haven’t to estimate new completion time. Thank god, I have a buffer week in my GSoD timeline and deliverables. So yeah, all is good in terms of completion time. I started to write descriptions for API endpoints. Submitted first PR and published blog entry.

Week 5

I managed to add a lot of stuff into the documentation. I figured out how to add help texts to classes and how to create serializers. I also managed to move all code examples under response samples. In order to do this, I created a new class called CustomAutoSchema to add x-code-samples. Other stuff that I did include creating new sections such as “Register and Authenticate” and “Glossary”. The hardest part of this week is probably trying to figure out how to add request body examples and move code examples.

Week 6

I added another section called Contribute that provides a todolist to start contributing on Github. I also wrote and published this blog post.

Week 7

I restructured the file README in CC Catalog API repository. I added a step by step guide on how to run the server locally. I hope new users will be less intimidated to contribute to this project with the updated guide on how to run the server locally.

Week 8

I created Documentation Guidelines which provides steps on how to contribute to CC Catalog API documentation, documentation styles, and cheat sheet for drf-yasg. I also wrote and published this blog post.

Week 9

I had completed all GSoD tasks by week 9. So, I took a couple of days off and fixed last week's PR. Kriti assigned me with new tasks, which is to port CC Catalog documentation from the internal wiki into GitHub repository. Brent, the CC Catalog maintainer explained to me about what needs to be done.

Week 10

I started exploring CC Catalog and its documentation. Reminds me a lot about the first and second weeks of GSoD. Trying to understand new stuff and having an "aha" moment when the dots finally connect. I started to move the documentation from the internal wiki to CC Catalog’s GitHub repository. I also wrote and published this blog post.

Week 11

I finished working on porting CC Catalog documentation from internal wiki to CC Catalog’s GitHub repository. Kriti told me that there would be a meeting in which I have to present what I've done for GSoD. Since the meeting will take place at 1AM in my local time, Kriti told me that I should send a video presentation instead.

Week 12

I submitted a video presentation to Kriti. Finished writing project report and evaluation for GSoD. I published 2 blog posts this week. One for updates on Week 11 and Week 12. Another one is this blog post.

You can view the latest CC Catalog API documentation here.

Finish Video Presentation, Project Report and Evaluation Form

2020-12-01T00:00:00Z

For week 10 and 11, I finished porting CC Catalog documentation, submitted a video presentation, and wrapped up my GSoD 2020 journey.

Week 11

For Week 11, I finished working on porting CC Catalog documentation from internal wiki to CC Catalog’s GitHub repository. Kriti told me that there would be a meeting in which I have to present what I've done for GSoD. Since the meeting will take place at 1AM in my local time, Kriti told me that I should send a video presentation instead.

Week 12

For this week, I submitted a video presentation to Kriti. Finished writing project report and evaluation for GSoD. I published 2 blog posts this week. One for updates on Week 11 and Week 12. Another one is a summary of my GSoD 2020 journey, which also serves as a project report.

Signing off.

Presenting CC Base docs - A WordPress Base Theme Usage Guide for the CC Base Theme

2020-11-27T00:00:00Z

We are live 🎉

The CC Base documentation is live and its available on this link.

The docs were successfully migrated from Google Docs to the site! One of the most notable changes in the theme and consequently reflected in the documentation is the product name change. The CC WP Theme Base has been renamed to CC Base.

But the old adage says good documentation is never complete, we hope to engage the Creative Commons Community and perform usability tests. Any feed back gathered from the usability tests will then be used to further improve the CC Base docs.

In future iterations of the docs development we hope to include the following features:

Increase the quantity of illustrative media so as to make the docs more intuitive this will be marked by adding video tutorials on how to use certain features of the CC Base theme and also adding illustrative tree diagrams to explain hierarchy of key directories and files in the CC Base project structure.
Integration of Algolia a software tool used to power search functionality in static generated sites.
We also hope to improve SEO for the site.

All the above mentioned improvements are geared at improving the overall user experience of the docs as well as ensure faster onboarding for our community members to get started on using the CC Base theme.

In conclusion I would like to thank all members of the Creative Commons engineering team, with special mention to Hugo Solar and Kriti Godey. Thank you for your guidance and faith in my abilities as a technical writer and software developer.

Vocabulary Site Updates (Part 3/n)

2020-11-25T00:00:00Z

Excited to know more about this week's vocabulary site updates? Read on to find out!

Vocabulary Site Updates (Edition 3/many more to come)

What I've been up to

The surreal feeling...

Merged? Yes. Merged. Here's my story!

After getting a thumbs up from the UX Designer, I put up my GSoD Website PR for review.
I was confident there would be changes, and I let them roll in. It's important to note here that what seems perfect to you may not be so to others, and only experience teaches you the right from the wrong.
There were a few of them, mainly dealing with spacing, textual content and colors. I resolved them as soon as I could.
zackkrida has been kind enough to point and enumerate all of them for me!
After receiving a final approval from the engineering team, my PR was finally merged!
The final draft of the vocabulary site is live! It will soon be deployed (on Netlify) and be made available for public viewing.
For my readers, here's exclusive preview of the final draft.
I've tried making it as optimised as possible, but if you have any inputs whatsoever feel free to raise issues over on our GitHub repository.
The famed Lighthouse report suggests that it's a pretty good start! I've also taken care of the accessibility aspect wherever applicable.

Aiming high!

What I've learnt

GSoD isn't just about documentation; there's some serious amount of coding too!
You don't have to sit and write code for hours together. Take breaks, come back, and the fix will strike you sooner than ever.
Timelines change; improvisation being an essential aspect of any project!
MDX is a neat little format to code in! Documenting code is just so much easier.
Things become obsolete. Versions become outdated. Code maintaining is therefore, easier said than done!

Other community work tidbits

Being a part of an open source organisation also means that I must try to bring in contributions from existing & first time contributors. Here's a peek into my efforts for the same:

The dark mode PR started off as a hacktoberfest contribution, and it is now complete!
Created a /shared package to house common files between packages (such as the dark & light theme after referring to the React documentation.
The automated npm README.md customisation is now up and running. (really had a blast solving that issue!)
If the snapshot testing stands approved, we'll have it running on chromatic!
Raised issues to add multiple badges to the root README.md file; namely maintained with Lerna & custom badges for package sizes from packagephobia.

Thank you for your time! Stay put for the season finale!

Finish GSoD Tasks and Explore CC Catalog Documentation

2020-11-20T00:00:00Z

Today marks my fifth blog entry on Creative Commons. For week 9 and 10, I explored CC Catalog documentation and began improving the documentation by removing keys and generalizing instructions.

Week 9

Week 10

For week 10, I started exploring CC Catalog and its documentation. Reminds me a lot about the first and second weeks of GSoD. Trying to understand new stuff and having an "aha" moment when the dots finally connect. I started to move the documentation from the internal wiki to CC Catalog’s GitHub repository. I also wrote and published this blog post.

End of blog entry.

Content Creation Phase: WordPress Base Theme Usage Guide

2020-11-10T00:00:00Z

For the past couple of weeks we have been actively creating content for the Creative Commons WordPress Base Theme Usage Guide. Currently the draft content is under final review before it is migrated to the main docs site.

Our Strategy

Our main goal in creating the docs is to create rich, intuitive, engaging, and beautifully presented community facing documentation for the Creative Commons WordPress Base Theme.

In alignment with the defined goal, our core focus is to create the docs collaboratively.

The CC WordPress team consists of I, Jacqueline Binya, Hugo Solar and Timid Robot Zehta. Although our team is small it is quite diverse. It consists of a diverse mix of technical skills: I am a junior developer whereas Hugo and Timid are way senior. We also have non-native and native English speakers.

Diversity is important as we hope to create a high quality product that caters for everyone.

My role as the tech writer/frontend developer is to create the content: write the documentation, build the docs site and also to create all illustrative media.

During the content creation phase, the first step involved creating the skeleton of the actual docs site. We created a git branch called docs within the creative-commons/wp-base-theme repository. All content related to the documentation is persisted in that branch. So,please feel free to contribute. We then used JamDocs, a Gridsome theme to quickly scaffold the site. We had to adapt the theme so as to make it meet our own specific needs, this involved overhauling the styles and changing the functionality of some of the features in the theme. After that was completed, we then created a Google Doc we use for collaboratively writing the draft content for the docs site.

Tech Stack

As it was mentioned we used Gridsome a static generator for Vuejs. We chose Gridsome because:

We wanted to lower the barrier of entry to contributing:
- Gridsome/Vuejs community is very active, help is but a click away.
- The Gridsome official documentation is very resourceful and well maintained.
Gridsome is highly flexible: The content for the actual documentation is written in Markdown but using @gridsome/vue-remark, which is a Gridsome plugin, we are able to use javascript in Markdown. We intend to include a copy to the clipboard Vuejs component in the site.
Time Constraint: This project is a short running project which has to be completed in a 3 month period. Through the use of JamDocs, a Gridsome templating theme as well various plugins it was easy and fast to get started we were able to add more functionality to the theme with minimal effort.
Ease of integrating CC Vocabulary with Gridsome: it is a requirement that the general aesthetics of all front facing Creative Commons applications is derived from the CC Vocabulary Design System. Major cons for using a design system include the ensuring uniformity in design for all front facing CC products.

Tools Used

Figma:

Figma was used to make assets(banners, logos and illustrations) in the theme. The illustrative media was created with accessibility in mind and all the topography used in the illustrative assets was derived from the CC Vocabulary.

VokoScreenNG: an open source screencast recording tool used to record all the screen cast demos available in the docs site.
ShortCut: an open source video editing tool.

What comes next ?

After the final review is completed and all feedback implemented we will migrate all the content to the main docs site.

Stay tuned for an update about the launch of the CC WP Base Theme Docs site.

Vocabulary Site Mid-Internship Update (v2)

2020-11-09T00:00:00Z

This is a mid-internship blog post. Wait. what!? Already? Let's glance over my progress, shall we?

Vocabulary Site Updates (Edition 2/many more to come)

Oh boy! 1.5 months have passed since I've been investing time in building a landing site & usage guide for CC Vocabulary. A lot has changed since the time of posting my last blog post. A lot.

Hitting "the point of no return" has never been this exciting! Time to step on the throttle! Source: Cliply

What I've been up to

Designing ⇨ Drafting ⇨ Developing ⇨ Debugging ⇨ Deploying

And the cycle contrinues. I guess it sums it all up very nicely. Can somebody appreciate the alliteration though?

Here's a gist of what I've achieved so far:

I've gone through 2 iterations of the design. I'm happy with how the new site looks (and I genuinely hope the design team does too!).
I've drafted around 5+ writeups dealing with Monorepo Migration, Getting Started guide, Vocabulary Overview and of course these blog posts.
My branch on the vocabulary repository now has over 50+ commits & over 13,000 lines of code (not that I've written all of them, but you know, just for the stats)
The first draft of the vocabulary site is now live! I'm expecting a whole bunch of changes still, but here it is if you want to have a sneak peek: https://cc-vocab-draft.surge.sh
I've consumed the Github API to get live release history, forks and starrers count. I think it adds a really nice touch to the site in general.
I've used surge.sh to deploy the draft site. I believe it's a really simple tool to have your site deployed within seconds!

My github contribution chart is filling up!

What I've learnt

Some say it's hard to learn through virtual internships. Well, let me prove you wrong. Here are my leanings in the past few weeks:

It's surprising how subjective (& yet objective) designing really is.
Vue.js is fantastic. Maybe I'm a Vue.js fan now. Should I remain loyal to React? I don't know.
Making a site responsive isn't the easiest of tasks, but it's certainly doable after a lot of stretching & compressing; lets say that.
"Code formatting is essential" would be an understatement to make.
Monorepo's have their own pro's and con's. But in our case the con's were negligible, thankfully!
I'll be following up with some performance & accessibility testing this coming week, so let's see how that plays out!
A mentor plays a vital role in any project. My mentor @dhruvkb has been very supportive and has made sure I stick to my timeline!

Other community work tidbits

I believe apart from the internship work that I'm engaged in, I should also help around with some community PR work. I've been told I'm always welcome to, which is great!

I got the opportunity to speak at a CCOS event alongwith fellow speakers dhruvkb & dhruvi16. I had a blast talking to budding students from DSC-IIT Surat & DSC-RIT.
The dark mode (as promised) should be out before my next blog post.
Deployed the vocabulary storybook on Chromatic and compared & contrasted the pros & cons. Snapshot testing in the near future maybe?
Completed the hacktoberfest challenge.

Bonus content

Not many of you may know this, but this site uses the Lektor CMS. I needed to have it installed on my system (windows 10 OS) to run the code in our site repository. Lektor suggests running the following code in powershell as an installation step:

(new-object net.webclient).DownloadString('https://www.getlektor.com/installer.py') | python

I just didn't think this is a very elegant way. Being an ardent chocolatey.org fan, I just had to have it up on there! Now the installation step for lektor is simply:

choco install lektor

on the Windows PowerShell!

Have a look at the package here:

https://chocolatey.org/packages/lektor

Thank you for your time! Stay put for the next Vocabulary site update!

Restructure README and Add Documentation Guidelines

2020-11-05T00:00:00Z

This is my fourth blog entry on Creative Commons. For week 7 and 8, I restructured the file README to be more digestible to new users and created Documentation Guidelines for CC Catalog API documentation.

Week 7

For this week, I restructured the file README in CC Catalog API repository. I added a step by step guide on how to run the server locally. I hope new users will be less intimidated to contribute to this project with the updated guide on how to run the server locally.

Week 8

For week 8, I created Documentation Guidelines which provides steps on how to contribute to CC Catalog API documentation, documentation styles, and cheat sheet for drf-yasg. I also wrote and published this blog post.

Finis.

Vocabulary Site Updates (v1)

2020-10-26T00:00:00Z

Hello there! Well well well. It has been an eventful first few weeks, to say the least! Let's gauge my progress, shall we?

Vocabulary Site Updates (Edition 1/many more to come)

What I've been upto

I've mainly got myself invested in a survey of the existing documentation that vocabulary currently possesses, and find places where it could be made better. After clearing those issues out, I began building the main landing site for Vocabulary, Vue-vocabulary and Fonts. It wasn't particularly difficult to establish the necessary workflows as I had done something similar before. During the process of designing the basic structure of the site, I came across a few instances where I felt we needed new/improved components & I discussed the same with my team over on the sprint calls. The design of the site is nearly done. I'm also building the site parallelly & seeking approval from the CC Design Team. I've gotten myself involved in multiple other community contributions to CC as well across multiple of our repositories.

What I've learnt

Knowing the previously existing code in your project is of serious essence. It's important to understand the code styles, structure & activity of the code that you are dealing with.
Be patient! Its fine to delay something if it makes sense to have it logically accomplished only after certain other tasks are done & dusted with.
How essential it is to write neat code is something that's not spoken too often. (I wonder why...)
I always thought VueJS sets up SPA's by default. I'm surprised you need to configure it additionally to do just that!
Storybook is just a really nifty OSS with great community support!

Other community work tidbits

I've been working on the Dark Mode (a much awaited feature, at least for me!) for our storybooks with some support from our community. It should be up and running shortly!
Fixed some formatting bugs in the README.md & suggested changes wrt to npm v7 considerations.
Fixed storybook components docs for 2 features.
Raised a ticket for a component to render markdown text within vocabulary itself.
Raised a few other issues for potential hacktoberfest contributions.

Thank you for your time! To be continued...

Add New Sections, Descriptions, Help Texts, Code Examples, Schemas, and Serializers

2020-10-21T00:00:00Z

Welcome to my third blog entry! For week 5 and 6, I added new sections, descriptions, help texts, code examples, schemas, and serializers. I was so productive these past two weeks.

Week 5

For this week, I managed to add a lot of stuff into the documentation. I figured out how to add help texts to classes and how to create serializers. I also managed to move all code examples under response samples. In order to do this, I created a new class called CustomAutoSchema to add x-code-samples. Other stuff that I did include creating new sections such as “Register and Authenticate” and “Glossary”. The hardest part of this week is probably trying to figure out how to add request body examples and move code examples.

Week 6

For week 6, I added another section called Contribute that provides a todolist to start contributing on Github. I also wrote and published this blog post.

All caught up!

Add Response Samples and Descriptions for API Endpoints

2020-10-09T00:00:00Z

Well, hello again 👋! For week 3 and week 4, I added response samples and descriptions for API endpoints. Writing documentation feels a bit like coding at this point because I need to read a lot about drf-yasg, dig through issues and questions at Github / Stackoverflow to ensure that I don’t ask redundant (or even stupid) questions.

Week 3

Week 4

For this week, I reviewed what I’ve done and what I haven’t to estimate new completion time. Thank god, I have a buffer week in my GSoD timeline and deliverables. So yeah, all is good in terms of completion time. I started to write descriptions for API endpoints. Submitted first PR and published blog entry.

Over and out.

Vocabulary Site & Usage Guide Introduction (GSoD'20)

2020-10-02T00:00:00Z

Hey there! I'm Nimish Bongale, a Technical Writer & Software Developer based out of Bangalore, India. My other hobbies include playing chess and the guitar. I look forward to build the CC Vocabulary site and usage guides as a part of GSoD'20.

But what is GSoD?

GSoD, or Google Season of Docs, is a program that stresses on the importance of the documentation aspect of Open Source projects. It invites technical writers from across the world to submit proposals based on projects floated in by the participating Open Source Organisations. The selected technical writers then work with the their respective organisations and look to complete their work by the end of their internship period. More information about the same can be found here.

Let's talk a bit about my project, shall we?

Vocabulary Site & Usage Guide

Introduction

CC Vocabulary is a cohesive design system & Vue component library to unify the web-facing Creative Commons. It's currently comprised of 3 packages, namely Vocabulary, Vue-Vocabulary & Fonts. My contribution to this project would majorly involve building the landing site for CC Vocabulary, and refactor the documentation wherever necessary.

What drives me

Documentation is one of the primary reasons which determines how successful a certain open source library will be. The major question that developers think of while choosing a suitable tech stack to build their applications is:

Is the library well documented?
Is it well maintained?
Does it have some considerable usage and error support?

These are exactly the questions I should be asking myself while going about this project idea.

As aforementioned, there is an immanent need to have a concise and consolidated documentation. The lack of documentation hurts the future perspectives of open source applications, and is by far, an essential and non-negligible component. Linking to these documentations should be an appealing home page, which captures the interest of the people in an instant. The documentation should be well organised, thereby enabling a seamless flow through it.

Tech stack of the project

We have decided to move forward with Vuejs for building the site, and continue work on the existing storybooks of Vocabulary, Vue-Vocabulary and Fonts. Storybookjs has had some great improvements in recent times, and the new addons that are offered will greatly support my work. Besides these, I will also be using StackEdit to write and share Markdown files of my writings.

Progress - Baby Steps

I have contributed to CC in the past. It would now be my first time contributing to a specific project within CC, while being a member of CC Open Source. Some tasks that I've been able to initiate/accomplish so far:

Look at Open Source documentation conventions, and see if we violate any.
Understand the level of existing documentation currently present in our storybooks.
Discuss about the Monorepo migration and help out with the implementation.
Migrate storybookjs to the latest version.
Implement addon-controls for vocabulary.
Design the vocabulary site.
Promote the involvement of CC Open Source in Hacktoberfest 2020.

What did I learn?

Design is more than just picking colors and placing components on a grey screen.
It's important to read your own writings from an unbiased perspective to actually understand how well it would be perceived.
Interacting with your mentor on a regular basis is of the absolute essence.
Publishing to npmjs is not difficult!

Thank you for your time!

Creative Commons WordPress plugin: attribution for images

2020-10-01T00:00:00Z

As a part of Centrum Cyfrowe's #NoWorries project funded by EUIPO, I have had the pleasure of enhancing the Creative Commons Wordpress plugin. The new version of CC's Wordpress plugin has a feature called “attribution information for images”. It works like this:

you upload an image to the Wordpress Media Library and fill out the correct attribution information there.
You then insert the image into a page using the Image Gutenberg block.
When the image is then displayed on site, the plugin will show the attribution information – the name of the author, the image's title and link to source, and the CC license used – right there, in a nice semi-transparent overlay over the image.

How does it work?

To find the relevant information from the Media Library, the plugin reuses the information already provided by Gutenberg Image Blocks. Each time an image is inserted using such a block, Wordpress adds a special CSS class to it, in the form of wp-image-{id}, containing the image's identifier in the Media Library. It can be used to add individual styles to a specific image – we're using it to find the relevant entry in the Media Library and add individual attribution information. With this approach, we avoid the need for any custom markup – while also only hitting the database with a query when an actual image from the Media Library is found on the page.

All you need to do is make sure the licensing information is there in the Media Library, and that the images are inserted using the Image block.

This wasn't the first attempt at adding a similar function to the CC Wordpress plugin. The previous attempt used a [license] shortcode wrapping the image – which it's unwieldy with the current Wordpress Gutenberg editor. It also used multiple calls to attachment_url_to_postid to locate the image in the Media Library, which meant executing more database queries for each image. With the new approach, the user doesn't have to change their posts at all – all they need to do is install the plugin and add attribution information in the Media Library, and it will automatically start working for their normally inserted images.

See here how to install the plugin:

See here how to use the image attribution function:

WordPress Base Theme Usage Guide (GSOD-2020): Hello World!

2020-09-30T00:00:00Z

My name is Jacqueline Binya. I am a software developer and technical writer from Zimbabwe. I am going to write a series of blog posts documenting my experience and lessons as I contribute to the Creative Commons WordPress Base Theme(CC WP Base Theme) during the Google Season of Docs (GSOD-2020) as a technical writer.

What is Google Season of Docs?

The Google Season of the Docs was born out of a need to improve the quality of open-source documentation as well as to advocate for open source, for documentation, and for technical writing. Annually during the GSOD, technical writers are invited to contribute to open-source projects through a highly intensive process geared at ensuring that the technical writers and the projects they contribute to during GSOD are a good fit, after that has been determined GSOD then resumes.

Building the docs

The CC WP Base theme is a WordPress theme used to create front-facing Creative Commons (CC) websites. My task is to collaborate with the engineering team to create community facing docs for the theme.

Guiding principles

The docs should be inclusive meaning: they should be written in an easy-to-understand manner taking care to avoid the use of excessive technical jargon, they should be accessible and they should have support for internationalization. We hope to provide our users with a smooth and memorable experience whilst using the docs hence the docs site should be fast and easy to navigate.

Technical stack of the project

We decided to build the docs using Jamstack, to be specific we are using Gridsome a static generator for Vuejs. We are using Gridsome as it is highly performant, and it also integrates smoothly with the CC Vocabulary. Gridsome also has out-of-the-box support for important features like Google Analytics and Angolia, these features will obviously be useful in future iterations of the docs. To quickly scaffold the docs we used a Gridsome theme called JamDocs.

Progress

Currently, the project is on track. As it's been stated we are creating the docs collaboratively. The very first step in our workflow is to create draft content using Google docs. That task is assigned to me, it involves doing lots of research, reading and also testing out the theme. Afterwards, my mentors Hugo Solar and Timid Robot Zehta then give me feedback on the draft. Then I implement the feedback and continuously work on improvements. The final step is migrating the approved draft content to the docs projects in markdown format.

My lessons so far:

Always ask questions: frankly, the only way you can create good content is when you have a solid understanding of the subject matter.
It's better to over-communicate than under-communicate especially when working in a remotely, this is especially more important if you encounter blockers whilst executing your work.
Push that code and open PR quickly and then go ahead and ask for a review don't procrastinate this will ensure fast turnover you get feedback quickly and can work on improvements.

Thank you for reading, watch out for the next update which will be posted soon.

Add Query Using curl Command and Provide Response Samples

2020-09-25T00:00:00Z

First of all, I’m very thankful to get selected as a Google Season of Docs participant under Creative Commons. My project name is Improve CC Catalog API Usage Guide. The project aims to revamp the existing CC Catalog API documentation to include more narrative elements and increase user friendliness. As the focal point of this project will potentially be delivered before the end of the GSOD period, this project will also improve the CC Catalog API repo documentation for potential contributors. This project will also produce guidelines for contributing to documentation. For this project, my mentor is Alden Page.

Week 1

Week 2

That’s all!

The specifics - Revamping CCOS

2020-09-02T00:00:00Z

In this blog, I will be talking about how I managed to use Vocabulary ( Creative Commons's Design Library ) efficiently in our Open Source website.

What is Vocabulary?

Vocabulary is a cohesive design system to unite the web-facing Creative Commons. In essence Vocabulary is a component library that uses and extends Bulma CSS library. Vocabulary makes it easier to develop Creative Commons apps while ensuring a consistently familiar experience. This project is still under development.

Why Vocabulary?

Vocabulary is used to describe the overall visual design of our digital products. At first glance, it appears to be: an amalgamation of component designs with a consistent visual aesthetic and brand, typically accompanied by usage guidelines in the form of online documentation. But there is a lot more to it. When it comes to a large software community with a huge range of products, certain problems come along. One of those problems is maintaining the level of harmony across all the products of the network. So, there comes a need for a unified visual language that heightens the level of harmony in a digital ecosystem. And in our case, Vocabulary solves this problem. This design system is well built and helps us bring the following aspects to the table -

Recognizability
Consistency
Authenticity
Efficiency

And many more.

How did I use it? — Examples

As I stated before, I have added Vocabulary by updating all the Templates in the CCOS Lektor project.

As far as components are concerned, I just had to paste the code snippets given on the Vocabulary’s website with the requires changes -

Screenshot — Breadcrumb (Vocabulary)

The code for integration —

<!-- Breadcrumb -->
  {% if this._path !=  '/'%}
    <div class="breadcrumb-container">
      <nav class="container breadcrumb caption bold" aria-label="breadcrumbs">
        <ul>
          {% set crumbs = [] %}
          {% set current = {'crumb': this} %}
          <!-- Extracting the slugs of URL -->
          {% for i in this._path.split("/") %}
            {% if current.crumb is not none %}
              {% if crumbs.insert(0, current.crumb._slug) %}{% endif %}
              {% if current.update({"crumb": current.crumb.parent}) %}{% endif %}
            {% endif %}
          {% endfor %}
          {% for crumb in crumbs %}
            <!-- Active link -->
            {% if this._slug == crumb %}
              <li class="is-active"><a aria-current="page displayed">{{ crumb | title | replace('-', ' ') }}</a></li>
            {% else %}
              <!-- Forming the URL using extracted slugs -->
              {% set i = loop.index %}
              {% set ns = namespace (link = '') %}
              {% for j in range(i) %}
                {% set ns.link = ns.link + crumbs[j] + '/' %}
              {% endfor %}
              <li><a class="link" href="{{ ns.link|url }}">
              {% if crumb != '' %}
                {{ crumb | title | replace('-', ' ') }}
              {% else %}
                Home
              {% endif %}
              </a></li>
            {% endif %}
          {% endfor %}
        </ul>
      </nav>
    </div>
  {% endif %}

Other than the components, there are other visual elements like typography, colors, spacing, and others that are extensively used in CCOS.

This is code for the Hero section of the home page.

The block template -

<section class="hero">
  <div class="container">
    <div class="hero-title column is-12 is-paddingless">
      <h1>
        {{ this.title }}
      </h1>
    </div>
    <div class="columns">
      <div class="column is-5">
        <p class="hero-description">
          {{ this.description }}
        </p>
        {{ this.links }}
      </div>
    </div>
  </div>
  <div class="level-right hero-image">
    <img class="image" src="./github.svg" />
  </div>
</section>

The block styling -

// Hero section - Home page
.hero {
  @extend .margin-top-large;

  .hero-title {
    @extend .padding-horizontal-big;
  }

  .hero-description {
    @extend .body-bigger;
    @extend .padding-top-big;
    @extend .padding-horizontal-big;
  }

  .hero-links {
    @extend .margin-vertical-normal;
    @extend .padding-horizontal-big;

    .button {
      @extend .margin-top-normal;
      text-decoration: none;

      .icon {
        @extend .margin-right-small;
        @extend .padding-vertical-smaller;
      }
    }
  }

  .hero-image {
    @include from($fullhd) {
      margin-top: -20rem;
      .image {
        width: 50%;
      }
    }
    @include until($fullhd) {
      .image {
        width: 100%;
      }
    }
  }
}

Output

Improvements in the Lektor project -

I tried to write the perfect code that is cleaner and readable. I would try to demonstrate my effort using the home page code where I used Lektor Flowblocks. The new homepage design have four sections where each section communicated something and I realized they were all independent and building the whole page through one single template would become a bit messy and hard to handle. So I did some research and found a way where I could build sub-templates and use them all to develop a single page and Lektor’s flowblocks allowed me to do so. Here is one of the flowblock and if you want to check out the whole working you can go to — CCOS Repository.

Recent Blog Post block -

The block Template -

{% from "macros/author_name.html" import render_author_name %}

<section class="recent-posts">
  <div class="container">
    <div class="level">
      <h2 class="is-paddingless level-left">
        {{ this.title }}
      </h2>
      <span class="level-right">
        <a class="posts-link" href="/blog">See all posts <i class="icon angle-right"></i></a>
      </span>
    </div>
    <div class="columns">
      {% for post in site.query('/blog/entries') %}
        {% if loop.index <= 3 %}
          {% set author = post.parent.parent.children.get('authors').children.get(post.author) %}
          <div class="column is-one-third is-paddingless padding-horizontal-big padding-top-bigger">
            <article class="card entry-post horizontal no-border blog-entry">
              <header>
                <figure class="image blog-image">
                {% if author.about %}
                  {% if author.md5_hashed_email %}
                    <img class="profile" src="https://secure.gravatar.com/avatar/{{ author.md5_hashed_email }}?size=200"
                    alt="gravatar" />
                  {% endif %}
                {% endif %}
                </figure>
              </header>
              <div class="blog-content">
                <h4 class="b-header"><a class="blog-title" href="{{ post|url }}">{{ post.title }}</a></h4>
                <span class="blog-author">by <a class="author-name" href="{{ author|url }}">{{ render_author_name(author) }}</a>
                on {{ post.pub_date|dateformat("YYYY-MM-dd") }}</span>
                <div class="excerpt">
                  {{ post.body | excerpt | string | striptags() | truncate(100) }}
                </div>
              </div>
            </article>
          </div>
        {% endif %}
      {% endfor %}
    </div>
  </div>
</section>

The block Model -

[block]
name = Recent Posts

[fields.title]
label = Title
type = string

The block styling -

// Recent-posts section - Home page
.recent-posts {
  background-color: rgba(4, 166, 53, 0.1);

  .container {
    @extend .padding-vertical-xl;
    @extend .padding-horizontal-big;

    .columns {
      @extend .padding-top-bigger;
      @extend .padding-bottom-xl;
    }
  }

  .blog-title {
    @extend .has-color-dark-slate-gray;
  }

  .posts-link {
    @extend .has-color-forest-green;
    @extend .body-normal;

    font-weight: bold;
    line-height: 1.5;
    text-decoration: none;

    .icon {
      @extend .has-color-forest-green;
      @extend .padding-left-small;
    }
  }
}

Output — Recent blog posts.

I would also like to point out the amazing Query functionality provided by Lektor where you can access the child pages of the root. Here I am accessing blog posts from our Blog page and limiting the count of posts to three.

Difference in Experience

The level of user experience has been significantly elevated due to the use of Vocabulary. I would like to point one of the major experience change here. The major part of the website is guidelines — we have guidelines for contributing, guidelines for how to join a community, guidelines for how to write a blog and many more. The new website has cleaner and readable guideline with a proper hierarchy and every piece of information is made accessible using secondary navigation.

Below are the images of some guidelines pages from new website.

Screenshots from new website

Below are the images of some guidelines pages from old website. You can see the difference of experience in both cases.

Screenshots from old website

How you can use Vocabulary and also contribute to it?

Vocabulary is very easy to use. It is intuitive, consistent and highly reusable. Vocabulary uses Storybook to present each visual element that makes it very convenient for a user to integrate Vocabulary in their project. The code snippets attached with every element can be copied as it is and can be used. The code snippets above indicate how the library can be used and how easily you can achieve desired web pages. For more details, you can visit usage guidelines.

Vocabulary is still under development, feedback and bug reports are welcome, fixes and patches even more so. Here is the link to contribution guidelines.

Accessibility and Internationalization: WrapUp GSoC 2020

2020-08-31T00:00:00Z

These is the final blog of my internship with CC. I am working on improving the accessibility of cc-search and internationalizing it as well. This blog is the conclusion of my work. These past 10 weeks with CC have taught me a lot and I am really grateful to have got this opportunity. The experience was just amazing and the poeple are so helpful I really enjoyed working with them and am looking forward to continue working with the CC team.

You can glance through my work through these blog posts:

The progress of the project can be tracked on cc-search

CC Search Accessiblity is my GSoC 2020 project under the guidance of Zack Krida and Ari Madian, who is the primary mentor for this project, Anna Tumadóttir for helping all along and engineering director Kriti Godey, have been very supportive.

CC technical blog

Sunsetting api.creativecommons.org

Removal Rationale

Next Steps

Related blog posts

Deprioritizing work programs

Quantifying the Commons: The end of an era

Quantifying the Commons: The end of an era

Day 1 was amazing, Day 90 is growth!

Automating the Smithsonian quarterly report

Automating the arXiv quarterly report

Lessons learned

What Next!

Goodbye for now

Quantifying the Commons: My Journey so far with outreachy

Project overview

A brief history I learnt about

Progress so far

Aligning the project better to the script requirements

One of the main script requirement is making the script repeatable

Another script requirement is making the script idempotent

Documentation on the project

Completing the three stages of report for existing scripts

Current status

Collaboration with mentors

Key takeways

Avoiding generative AI development tools

Overhyped

Inefficiency and slop

Counterproductive

Responsibility and solidarity

References

Refactoring and Releasing the new CC Chooser: Part 2

Reevaluating core features and use

Turning scope into technical methods

Reducing the JavaScript footprint and overhead

Embrace native support and semantics

Improving the UX

Reducing friction

Adding friction

Better related UX element binding and separation

Increasing plasticity

Closing

Refactoring and Releasing the new CC Chooser: Part 1

What’s the Chooser?

Circumstances and context

Building an ecosystem from a strong core product

Shifting circumstances

The 2020 Chooser in limbo

Laying groundwork for a refactor and release

Moving forward

Migrating from MariaDB 10.4 to 10.11 on AWS RDS

Pre-Migration Steps

Create a DB Parameter Group

Create an Option Group

Perform the MariaDB Version Upgrade

How to Perform the Migration

Verify the Migration

Post-Migration Clean-Up

Conclusion

Best Practices

References

Reflecting On My Outreachy Journey With Creative Commons

From Day One to Now: The Journey

Refactoring the Issue Finder: Removing Vue for a Simpler Setup

Working with DataTables: A Whole New Learning Curve

From Midterm to Now: Wrapping Up and Final Contributions

Improving the Search Portal

CC Legal Database(LegalDB): Planning for Future Work

What’s Next?

A Heartfelt Goodbye (For Now!)

Finding Problems, and Exercising Compassion

Context matters

Pause for compassion

Without context assume the best

Safe to learn and safe to improve

Outreachy Midpoint Progress With Creative Commons

Outreachy Midpoint Blog Post

Project Overview

Progress So Far