Selection Criteria

Each applicant to The Palisadoes Foundation’s Talawa programs will be assessed using the following criteria

1. Contributions to the Talawa repositories
2. Communication Skills
3. Proposal Quality and End User Impact
4. Technical Knowledge & Skill

The above broad criteria will be expanded on below.

Criteria

Read this carefully.

Contributions

Contribution evaluation factors include:

1. Higher weighting to recent contributions, especially those done during formal evaluation periods as in the GSoC and Calico programs.
2. The quality of Issues and Pull Requests (PR)
   1. We consider the person’s displayed competence in the code base. Consistent meaningful PR contributions show commitment and hence value. You are much better served submitting fewer, higher quality PRs that showcase your abilities.
   2. Focus on the priorities stated in our Getting Started - Developers YouTube channel playlist.
   3. Don't submit low quality Issues and PRs. These are ignored when assessing participants. Do not get a reputation for doing this.
3. The impact of your merged PRs to our software.

In summary be a conscientious contributor to our long term goals of sustainable software development for the unmet needs of community based organizations.

Proposals

The quality of the submitted proposals are important.

Communication Skills

We value collaboration greatly. Therefore, the value of your participation in the community will be assessed. This includes your:

1. Behavior and Attitude toward mentors and other contributors
   1. Were participants respectful when interacting with others?
   2. Did participants handle disputes appropriately?
   3. Did participants perform any malicious actions to gain an unfair advantage for themselves or to deter others?
2. Knowledge in using collaboration tools such as GitHub
   1. Appropriate format for contributions were used when creating issues and PRS
   2. Accuracy when following contribution guidelines
   3. Collaboration tools were used appropriately (i.e. Bad practices such as ‘force pushes’ in git were not used)

Our contributors are spread out around the globe from cultures and backgrounds unknown to you. Each repository has a CODE_OF_CONDUCT.md file outlining additional steps you can take to be a better participant.

The End User Perspective

We highly value proposals that consider practicability, long term support, usability, and the perceived value to both the administrator and user. Limiting your solution to only the desired outcome discussion points will not give you an advantage.

Innovation

Our ideas list gives an outline of what we'd like to see implemented, but do not limit your proposal to this bare minimum. Copying feature functionality from other sources without improving upon them is insufficient, Talawa must always be better. Expand on the possibilities to meet our innovation requirements. We greatly value innovative features and approaches.

Front End

When the idea has a focus on the end user always consider new or updated features that will be:

1. Likely to be used extensively
2. Intuitive to use
3. Valuable to the end user

Always evaluate how the feature will make the administrator more likely to try Talawa.

This will mean in addition to screenshots and screen designs, you'll need to explain the logic in the sequencing of screens. If the design is unintuitive or the flow is complicated, users won't accept it. We consider all technically sound proposals. The ones that are harder to navigate will have a disadvantage.

Back End

Innovation behind the scenes should cover:

1. Ease of management by DevOps teams that may have limited experience.
2. Improving performance, scalability and reliability

Talawa is an open source project with mostly documentation as a technical support resource. The ease of use will always need to be considered.

Technical Knowledge and Skill

You should have experience in the technologies we use in the projects. You will not be effective without it. We therefore expect:

1. Knowledge of our tech stack (Flutter, NodeJS, Mongo, etc.)
   1. Experience using our stack
   2. Previous projects to show affinity with our stack
   3. Willingness to learn our stack
2. Knowledge of deploying systems
   1. Deploying backend applications to cloud services
   2. Deploying frontend applications to appropriate mobile stores (Google Play Store & Apple App Store)
3. Ability to finish the tasks in a prompt manner and create a productive workflow.
   1. Ability to independently work on an issue or feature
   2. High standards of code quality. It must be:
      1. Maintainable (eg. using widely supported, non EOL, production ready libraries),
      2. Readable,
      3. Documented,
      4. Verifiably testable

We want you to be successful, and these requirements help to ensure this happens.

Mentor Interaction

You will find the mentors listed in our ideas pages. They are the ones who evaluate and select projects. Though the Primary mentor leads the decision-making of the team, all their opinions are taken into account.

There are many ways to effectively contact mentors. Don't rely on just one form of communication. Try using:

1. DMs via our Slack community
2. The email addresses listed in the application process guide for feedback on your draft proposals
3. GitHub

Ask them to:

1. Review your PRs,
2. Provide feedback on the ideas pages,
3. Comment on GitHub discussions about PRs and ideas pages,
   1. Please do not @ them in the issue comments, ask the issue creators or the listed contacts in the issue descriptions for details.

Focus your mentor interactions to PR and internship ideas on slack and GitHub (PRs and Discussions only). You can @ them there for best results. That's the most efficient use of their time. When mentors get DMs, they realize they are needed and the more likely they will check slack and GitHub more frequently.

Read the Application Process pages for your internship of choice on this website for additional guidance.

Ranking

We review all project proposals, and rank them based on their:

1. likelihood of solving a material deficiency and/or,
2. the urgency of providing desired new or updated features.

This can change based on the:

1. progress of implementing other new features
2. acceptance of customized proposals into our consideration set.
3. acceptable quality of proposals

This may mean that project ideas we define with clearly defined goals may be displaced by one or more customized proposals in our ranking.

There is also no guarantee that we get sponsors for all the proposals we submit.

In some cases, we may take a chance on someone with potential versus experience.

In other words, selection is based on:

1. need,
2. talent,
3. thoroughness,
4. the ability to deliver and,
5. inventiveness.

Each selected proposal has this in varying degrees of weight. It’s not straightforward, and we try to be objective to the best of our ability.

Remember, the needs of the stakeholder using the app and the ability of the code base to meet them in the simplest, most intuitive and maintainable way will always take precedence.

In the past we published the number of GSoC slots requested, slots received and the ranking of proposals. This created a lot of over-analysis and misunderstandings which was unhealthy. We now have a policy of not providing this information for any internship program.

Each year, we may approach unsuccessful candidates to become formal contributors to the Palisadoes Foundation's GitHub account. This small group will have a wide range of experiences and abilities. In many cases we will be taking a chance. We hope this will encourage you to remain active, improve, add features and be more prepared for your careers and subsequent internship programs either with us or other organizations. This is not a guarantee for selection in our future programs. Formal contributors will have their PR approvals count in GitHub's automated ability to merge the code if all the tests pass.

Risk Mitigation

Competition for our internship programs is tough. We encourage participants to submit multiple proposals. In the past, we noticed people only submitting proposals for the high priority ideas we listed. This was very limiting. To improve the range of useful goals on our product road map, we created the hybrid project idea. This helps people to explore new avenues of innovation where you can differentiate themselves.

Minimum Requirements

We need to maintain good code quality therefore we maintain general minimum requirements for any participant that we assess.

General

We expect that:

1. Participants should have at least one properly closed issue and merged PR made on the repository
2. Participants should be receptive to any feedback given to them from mentors
3. Access to all required hardware and software for development on our project
4. Access to a stable internet connection

Without these prerequisites you will not be successful.

Focus Areas

These are some general focus areas for our applications by repository.

1. Talawa Front End (Web & Mobile)
   1. UI/UX designs & reviews
   2. Development of UI
   3. Development of Features & Functions
   4. GraphQL
   5. Security
2. Talawa API Backend
   1. MERN stack
   2. GraphQL
   3. Security
   4. Performance
3. Talawa Admin Web Portal
   1. TypeScript
   2. GraphQL
   3. Security
4. DevOps
   1. Deployment of Front and Back End
   2. CI/CD Pipeline for Front and Back end
   3. QA

NB: Participants will have to work on multiple aspects of the application, but breaking it down will give everyone a more “clear cut” role when they’re deciding what to work on. (i.e. A student won’t be accepted if they're only willing to do UI/UX designs and reviews. If a student would like to work on all areas related to the front end, that would be fine.)

Mentors may at any point decide to hold an interview with any applicant to decide whether they are suitable for selection. This is completely optional, so participants may be accepted without participating in an interview.