Skip to main content

GSoC Ideas

NOTE: These ideas are subject to change at any time prior to us submitting our GSoC 2025 Organization application. Ideas may be added, removed or updated up to this time.

If we are accepted, there may be additions and minor modifications.

Introduction​

Welcome to our GSoC ideas page! Get familiar with our general philosophy by reading this section. The ideas follow afterwards.

General Considerations​

This is not an exhaustive list of ideas, but they broadly classify the types of features on which we'd like to focus our attentions.

You are open to propose your own solutions.

  1. We encourage candidates to think laterally.
  2. Take the initiative and consider something hybrid taking thoughts from various ideas posted here or something totally new.

We want ideas that will have a material impact on the project

Remember, the ideas list is just a guide for what we feel could be achieved, and not a strict list of requirements. Think of the overall goal of making a better product. Picking a subset of suggestions and expanding them beyond our expectations shows your initiative.

NOTE: If you feel the project ideas will take too much time as stated, then:

  1. Add that to your proposal
  2. Include what you think a reasonable scope should be.

We need your ideas to be completed on time with 100% test cases with each PR.

  1. Brittle code that breaks easily does not help the project
  2. Incomplete functionality is not acceptable unless specifically stated.

If there are any dependencies on other project ideas, then state it. Also include additional or alternative things that you would do if the dependencies are not completed in your desired time frame

The project is so much in its infancy that we'll accept any good idea that users will want or will facilitate that they could want. They must significantly advance our goal of having an MVP within the year.

We also welcome any other ideas that we could use. Please review the "Desired Features" section of this website for even more ideas and further necessary information.

Internship Participants​

Many of you reading this page are interested in participating in our various internship programs (eg. Google Summer of Code, GitHub Externship, Google Summer of Docs, Outreachy, etc.).

  1. Make sure to read the relevant Introduction and Application Guide/ Contribution Process pages first.
    1. GSoC Introduction.
    2. GSoC Application Guide.
  2. Review the Selection Criteria to ensure you meet all the requirements for a good proposal.
  3. Use the Application Template as a guide to formatting your application. The tips on this page are very important.

Good luck!

Documentation​

We need to reduce the learning curve of contributors and sysadmins alike. Project work needs to be well documented in our code so that tools can eventually automatically add it to our documentation websites.

Testing​

All code submitted must be tested. We are working towards getting to 100% test code coverage on all repositories. This will mean that you will have to write tests for new code you write or modify.

The test percent code coverage requirement will incrementally rise with each pull request. In some cases you may have to write a few extra tests for code you may not have updated. We hope this will be rare.

Write code that will work in the long term. Eliminate brittle code that will easily break.

Repository Languages and Skills​

Here is a list of basic skills that will be required for each repository.

  1. Talawa: Flutter / Dart, GraphQL
  2. Talawa-API: Typescript, GraphQL, MongoDB
  3. Talawa-Admin Portal: TypeScript
  4. Switchmap-NG: Python
  5. Pattoo: Python

There are others, but these are the primary ones that will guide your contributions.

Impact Definition​

We have categorized the various ideas according to the degree of impact they will have to the project. Use these definitions to understand how each idea will affect our overall project goals.

  1. Low-hanging fruit: These projects require minimal familiarity with the codebase and basic technical knowledge. They are relatively short, with clear goals.
  2. Risky/Exploratory: These projects push the scope boundaries of our development efforts. They might require expertise in an area not covered by our current development team. They might take advantage of a new technology. There is a reasonable chance that the project might be less successful, but the potential rewards make it worth the attempt.
  3. Fun/Peripheral: These projects might not be related to the current core development focus, but create new innovations and new perspective for our project.
  4. Core development: These projects derive from the ongoing work from the core of our development team. The list of features and bugs is never-ending, and help is always welcome.
  5. Infrastructure/Automation: These projects are the code that our organization uses to get our development work done; for example, projects that improve the automation of releases, regression tests and automated builds. This is a category in which a contributor can be really helpful, doing work that the development team has been putting off while they focus on core development.

Difficulty​

Most of our project ideas require knowledge of two or more programming languages. Meaningful PRs that prove your understanding of the repos will always be beneficial. We have created testing issues specifically for this purpose.

  1. Hard: Requires dominion of the language used by the repo most affected by the project. A good working knowledge of the languages used by other affected repositories will be needed.
  2. Medium: A good working knowledge of the languages used by affected repositories will be needed.
  3. Easy: A beginner's level knowledge of the languages is sufficient.

Ideas​

Coming Soon!