List of ideas.
Let's start with Client documentation, Welcome to the Ignitus Design System – an open-source library of React components for creating features @ignitus. It was originally created to help our teams work faster together, but it can be easily adapted to create applications with the look and feel of your own experience.
We created this Design System with several goals in mind:
To document components, patterns, and design guidelines, all in one place.
To ensure consistency in our code and design.
To standardise the visual language and experience of our products.
To provide guidance on the correct usage of the patterns.
To streamline our design and development.
It is a great platform to inform, inspire, promote and be the single source of truth for everybody within organisation working on different features.
We perceived that newcomers find it difficult to understand the workflow of existing UI components in turn difficulty in contributing to projects.
Contributors work in different ways & styles, they work with different tools and they all work at different levels of maturity in turn ended up with their own implementation.
It will be helpful to those who are willing to contribute to design system alone.
It is a collection of React UI components for quickly building user interfaces at our organisation, sooner we plan to publish it as an NPM Package as well. 🍻
You should check out our living style guide, which contains list of components unfortunately. At the moment, we are missing insightful documentation for our library.
Now let's move to API documentation.
The main objective is to document API in such a way that it would be easily understandable to new and existing contributors. As we believe a well-documented API and usage/ use-case document can assist in overcoming the bottleneck of trying out the APIs.
A use-case of the API, with some conceptual definition indicating what purpose a particular api call serves.
A use-case of the API, depicting payload structure sent by the client.
A use-case of the API, depicting required/optional properties sent by the client.
A use-case of the API, depicting type of request sent by the client.
That's all we want to accomplish with Google season of Docs 😃.
Moderate
We would be delighted to have understandable & simple human-friendly documentation enhancing design system experiences of our users.
It would be great if almost all the resources served by our API are documented.
It would be great if API & Design System docs should be easily understandable by contributors.
A great documentation, where everything we need is effortlessly communicated.
Experience with technical writing.
Brief knowledge of languages, frameworks etc used at Ignitus.
Motivation & Enthusiasm towards our mission at Ignitus.
Divyanshu Rawat & Afelio Padilla
Paarmita Bhargava & Mayur Sarvaiya
Note: Feel free to contact us on slack if you have any Questions :)
Together we raise awareness of open source, of docs, and of technical writing.
(Excerpt from Google's Season of Docs)
The goal of Season of Docs is to provide a framework for technical writers and open source projects to work together towards the common goal of improving an open source project's documentation.
Let's bring open source and technical writer communities together, to the benefit of both. Together we raise awareness of open source, of docs, and of technical writing.
For further information on GSOD please refer its docs. 📒
All communication should happen in Slack, GitHub.
You can start exploring project ideas towards the GSOD application phase.
You can get yourself familiar with our technical architecture. 🚀
You can review project ideas & ask Questions.
It would be great if you start writing your experience.
We suggest to plan a schedule for weekly meetings with your mentor.
If you want you can stay involved with the Organisation.
You can also volunteer to mentor in next GSOD.
Thanks for reading 📖, navigate to next page for project ideas.