├── .github ├── CODEOWNERS ├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.md ├── ISSUE_TEMPLATE │ ├── discuss-a-change-or-addition.md │ └── question.md ├── PULL_REQUEST_TEMPLATE.md ├── README.md ├── config.yml └── stale.yml ├── .gitignore ├── LICENSE ├── _index.md ├── assets ├── Online Room booking.pdf ├── av-cell-contacts.jpg ├── av-cell-requisition-form.pdf └── room-booking-form.pdf ├── community ├── _index.md ├── about-us.md ├── accounts.md ├── code-of-conduct.md ├── event-checklist.md ├── governance-review-week.md ├── governance.md ├── onboarding-offboarding.md ├── one-on-one.md ├── posters.md ├── recruitment.md └── socials.md └── events ├── _index.md ├── elastic-search.md ├── freshers-selection.md ├── git-and-github.md ├── kossprint.md ├── kwoc.md ├── lightning-talks.md └── room-booking.md /.github/CODEOWNERS: -------------------------------------------------------------------------------- 1 | # This file is used to automatically request review to some people for some aspects of KOSS documentation. 2 | # Read more about code owners here - https://help.github.com/articles/about-code-owners/ 3 | # Be very conservative with this file. Keep the documents and owners limited. Follow /.github/CONTRIBUTING.md#how-is-a-change-reviewed for the review process. 4 | 5 | /community/governance.md @OrkoHunter @kshitij10496 @madan96 @pranitbauva1997 @nitinkgp23 @DefCon-007 @Parth-Vader 6 | /community/history.md @OrkoHunter @kshitij10496 @madan96 @pranitbauva1997 @nitinkgp23 @DefCon-007 @Parth-Vader 7 | /about.md @OrkoHunter @kshitij10496 @madan96 @pranitbauva1997 @nitinkgp23 @DefCon-007 @Parth-Vader 8 | /accounts.md @OrkoHunter @kshitij10496 @madan96 @pranitbauva1997 @nitinkgp23 @DefCon-007 @Parth-Vader 9 | -------------------------------------------------------------------------------- /.github/CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Contributor Covenant Code of Conduct 2 | 3 | ## Our Pledge 4 | 5 | In the interest of fostering an open and welcoming environment, we as 6 | contributors and maintainers pledge to making participation in our project and 7 | our community a harassment-free experience for everyone, regardless of age, body 8 | size, disability, ethnicity, sex characteristics, gender identity and expression, 9 | level of experience, education, socio-economic status, nationality, personal 10 | appearance, race, religion, or sexual identity and orientation. 11 | 12 | ## Our Standards 13 | 14 | Examples of behavior that contributes to creating a positive environment 15 | include: 16 | 17 | * Using welcoming and inclusive language 18 | * Being respectful of differing viewpoints and experiences 19 | * Gracefully accepting constructive criticism 20 | * Focusing on what is best for the community 21 | * Showing empathy towards other community members 22 | 23 | Examples of unacceptable behavior by participants include: 24 | 25 | * The use of sexualized language or imagery and unwelcome sexual attention or 26 | advances 27 | * Trolling, insulting/derogatory comments, and personal or political attacks 28 | * Public or private harassment 29 | * Publishing others' private information, such as a physical or electronic 30 | address, without explicit permission 31 | * Other conduct which could reasonably be considered inappropriate in a 32 | professional setting 33 | 34 | ## Our Responsibilities 35 | 36 | Project maintainers are responsible for clarifying the standards of acceptable 37 | behavior and are expected to take appropriate and fair corrective action in 38 | response to any instances of unacceptable behavior. 39 | 40 | Project maintainers have the right and responsibility to remove, edit, or 41 | reject comments, commits, code, wiki edits, issues, and other contributions 42 | that are not aligned to this Code of Conduct, or to ban temporarily or 43 | permanently any contributor for other behaviors that they deem inappropriate, 44 | threatening, offensive, or harmful. 45 | 46 | ## Scope 47 | 48 | This Code of Conduct applies both within project spaces and in public spaces 49 | when an individual is representing the project or its community. Examples of 50 | representing a project or community include using an official project e-mail 51 | address, posting via an official social media account, or acting as an appointed 52 | representative at an online or offline event. Representation of a project may be 53 | further defined and clarified by project maintainers. 54 | 55 | ## Enforcement 56 | 57 | Instances of abusive, harassing, or otherwise unacceptable behavior may be 58 | reported by contacting the project team at contact@kossiitkgp.org. All 59 | complaints will be reviewed and investigated and will result in a response that 60 | is deemed necessary and appropriate to the circumstances. The project team is 61 | obligated to maintain confidentiality with regard to the reporter of an incident. 62 | Further details of specific enforcement policies may be posted separately. 63 | 64 | Project maintainers who do not follow or enforce the Code of Conduct in good 65 | faith may face temporary or permanent repercussions as determined by other 66 | members of the project's leadership. 67 | 68 | ## Attribution 69 | 70 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, 71 | available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html 72 | 73 | [homepage]: https://www.contributor-covenant.org 74 | 75 | For answers to common questions about this code of conduct, see 76 | https://www.contributor-covenant.org/faq 77 | -------------------------------------------------------------------------------- /.github/CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # How to contribute? 2 | 3 | We are really glad you are reading this. We want to keep KOSS documentation up-to-date all the time. 4 | 5 | ## 1. Something is bugging you 6 | 7 | If you want to discuss a section, a doc or the entire documentation, create a GitHub issue. You can additionally tag some people if you want their inputs. 8 | 9 | ## 2. Something needs to be changed 10 | 11 | You are awesome! You will have to create a Pull Request. Fork the repository, create a new branch, make the changes, and submit a Pull Request. You can read more about Pull Requests [here](https://help.github.com/pull-requests/). 12 | 13 | Stick to the following conventions - 14 | 15 | ### Conventions 16 | - Look for an existing doc or section where your content may go. If you can not find any, create a new document at an appropriate index. 17 | - Do not write anything as an opinion. 18 | - Do not rush through the content, hence write slowly. (A content written in haste, causes uneasiness to the reader.) 19 | - It is discouraged to write in first person *i.e.* do not use `I` or `Me`. NEVER write anything in first person without identifying who wrote it. (e.g. Name, Class of 'YY) 20 | - Check for spelling and grammatical mistakes. 21 | - You can use [Grammarly](https://app.grammarly.com/) to verify. You can get a [free grammarly account](https://wiki.metakgp.org/w/How_to_get_free_Grammarly_premium_account) if you are an IIT KGP student. 22 | - Sign your commits. [Read more](https://help.github.com/articles/signing-commits/) 23 | - Make 1 commit per change. Do not commit multiple changes together if they do not serve a single purpose. 24 | - Prefer 1 commit per Pull Request. This will keep the discussions separate and precise to the change. 25 | - Always write a clear log message for your commits. One-line messages are fine for small changes, but bigger changes should look like this: 26 | ``` 27 | $ git commit -S -m "A brief summary of the commit 28 | > 29 | > A paragraph describing what changed and its impact." 30 | ``` 31 | - Writing meaningful commit messages is important. We are interested in the changelog of KOSS documentation through the commit history of this project. 32 | 33 | Refrain from using Slack to discuss any queries related to a doc or any discussion about a serious change. Create an issue here and notify on the Google group about the GitHub issue. You can additionally send a direct email asking for inputs, to any advisor/alumni who might not be actively receiving emails from the Google Group or GitHub. 34 | 35 | 36 | # How is a change reviewed? 37 | 38 | - Do not merge any Pull Request within 48 hours of its creation. 39 | - At least x [TBD] approvals from Executive Heads is required. 40 | - At least x [TBD] approvals from Advisors/Alumni is required. 41 | - Do not merge a Pull Request which you have created yourself. 42 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/discuss-a-change-or-addition.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Discuss a change or addition 3 | about: Suggest an update in KOSS Documentation 4 | title: '' 5 | labels: enhancement 6 | assignees: '' 7 | 8 | --- 9 | 10 | # We STRONGLY RECOMMEND you to Create a Pull Request instead of an issue. This applies to making a change or adding anything new. 11 | 12 | This policy helps us collect all the discussions at one place. 13 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/question.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Question 3 | about: Use this template to ask a question about anything in KOSS Documentation 4 | title: "[Query]" 5 | labels: question 6 | assignees: '' 7 | 8 | --- 9 | 10 | **Give references** 11 | Quote `>` the section(s) you are referring to. Add URL(s) as well. 12 | 13 | **What is your question?** 14 | 15 | **Tell us who you are** 16 | If you are a member of KOSS, write your name and year of joining. If not, give some ways in which we can recognize you. 17 | -------------------------------------------------------------------------------- /.github/PULL_REQUEST_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | ### Notes: 2 | - Read [.github/CONTRIBUTING.md](https://github.com/kossiitkgp/docs/blob/master/.github/CONTRIBUTING.md) before creating the Pull Request. This is a MUST. 3 | - KOSS Documentation is public. Make sure you are not adding any information which should remain private. 4 | 5 | **Write path(s) which will be affected by this Pull Request.** 6 | Example: 7 | - `/community/governance` 8 | - `/events/index` 9 | - `/new-section/new-article` 10 | 11 | **Justify your changes or addition.** 12 | 13 | **Why do you think it should be documented?** 14 | 15 | Will sharing this with just the current members serve our purpose? For example, how you plan to conduct an event next week is a private affair. But, how you generally do the event, should be documented. 16 | -------------------------------------------------------------------------------- /.github/README.md: -------------------------------------------------------------------------------- 1 | # KOSS Documentation 2 | 3 | KOSS Documentation is meant to be read and followed by the members of KOSS. We keep the docs public because 4 | - We want every written line to be questioned and discussed regularly. More eyes help us achieve that. 5 | - We want to be as open as possible with our standards 6 | - We want to share our methods with sister organizations, if they need help. 7 | 8 | **Read [`/.github/CONTRIBUTING.md`](/.github/CONTRIBUTING.md) before making any change** 9 | -------------------------------------------------------------------------------- /.github/config.yml: -------------------------------------------------------------------------------- 1 | # Configuration for new-issue-welcome - https://github.com/behaviorbot/new-issue-welcome 2 | 3 | # Comment to be posted to on first time issues 4 | newIssueWelcomeComment: | 5 | 👋 Thanks for opening your first issue here! If you're asking a question, please allow some time for people to get back to you. 6 | 7 | If you have a new change to submit, please close this issue and open a Pull Request instead. 8 | 9 | To help make it easier for us to investigate your issue, please follow the [contributing guidelines](https://github.com/kossiitkgp/docs/blob/master/.github/CONTRIBUTING.md). 10 | 11 | # Configuration for new-pr-welcome - https://github.com/behaviorbot/new-pr-welcome 12 | 13 | # Comment to be posted to on PRs from first time contributors in your repository 14 | newPRWelcomeComment: | 15 | 💖 Thanks for opening this pull request! 💖 16 | 17 | Please read our [contributing guidelines](https://github.com/kossiitkgp/docs/blob/master/.github/CONTRIBUTING.md) thoroughly and make sure you follow it. 18 | 19 | If you are making any changes to any written content of KOSS Documentation - 20 | - The Pull Request must not be merged within 48 hours. 21 | - Please do not merge your Pull Request yourself, even if you have access to do it. 22 | - You need atleast 6 approvals (3 each from Executive Heads and Advisors) 23 | - Feel free to mention some people in the PR. 24 | -------------------------------------------------------------------------------- /.github/stale.yml: -------------------------------------------------------------------------------- 1 | # Number of days of inactivity before an issue becomes stale 2 | daysUntilStale: 60 3 | # Number of days of inactivity before a stale issue is closed 4 | daysUntilClose: 7 5 | # Issues with these labels will never be considered stale 6 | exemptLabels: 7 | - pinned 8 | - security 9 | # Label to use when marking an issue as stale 10 | staleLabel: wontfix 11 | # Comment to post when marking an issue as stale. Set to `false` to disable 12 | markComment: > 13 | This issue has been automatically marked as stale because it has not had 14 | recent activity. It will be closed if no further activity occurs. Thank you 15 | for your contributions. 16 | # Comment to post when closing a stale issue. Set to `false` to disable 17 | closeComment: false 18 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | .vscode -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2019 Kharagpur Open Source Society 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /_index.md: -------------------------------------------------------------------------------- 1 | # KOSS Documentation 2 | 3 | ## Index 4 | 5 | ### [Community](/community) 6 | 7 | - [Governance Week Review](/community/governance-review-week.md) 8 | - [Governance](/community/governance.md) 9 | - [Onboarding/Offboarding](/community/onboarding-offboarding.md) 10 | - [1:1](/community/one-on-one.md) 11 | 12 | ### [Events](/events) 13 | To get more beginners introduced to Open Source, we hold events like 14 | 15 | - Kharagpur Winter of Code 16 | - Ubuntu Install Fest 17 | - Version control (Git + GitHub workflow) 18 | - Various workshops 19 | - Python Classes 20 | - Golang Classes 21 | - Javascript classes 22 | - Android Development 23 | - Hackathons 24 | 25 | 26 | ## How to contribute? 27 | 28 | You do not need to be a KOSS member to contribute to KOSS Documentation. If you have any questions related to any doc but do not have, any changes to propose, go ahead and create an Issue. If you want to propose any change, create a Pull Request. Read [CONTRIBUTING.md](https://github.com/kossiitkgp/docs/blob/master/.github/CONTRIBUTING.md) before making any change. 29 | -------------------------------------------------------------------------------- /assets/Online Room booking.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kossiitkgp/docs/63b547dfe65ed406cb61f8038d3fe7921d73b3f4/assets/Online Room booking.pdf -------------------------------------------------------------------------------- /assets/av-cell-contacts.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kossiitkgp/docs/63b547dfe65ed406cb61f8038d3fe7921d73b3f4/assets/av-cell-contacts.jpg -------------------------------------------------------------------------------- /assets/av-cell-requisition-form.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kossiitkgp/docs/63b547dfe65ed406cb61f8038d3fe7921d73b3f4/assets/av-cell-requisition-form.pdf -------------------------------------------------------------------------------- /assets/room-booking-form.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/kossiitkgp/docs/63b547dfe65ed406cb61f8038d3fe7921d73b3f4/assets/room-booking-form.pdf -------------------------------------------------------------------------------- /community/_index.md: -------------------------------------------------------------------------------- 1 | # Community 2 | 3 | All the docs related to the closed community of KOSS. 4 | 5 | - [Governance Week Review](/community/governance-review-week.md) 6 | - [Governance](/community/governance.md) 7 | - [Onboarding/Offboarding](/community/onboarding-offboarding.md) 8 | - [1:1](/community/one-on-one.md) 9 | - [Recruitment](/community/recruitment.md) 10 | -------------------------------------------------------------------------------- /community/about-us.md: -------------------------------------------------------------------------------- 1 | +++ 2 | toc=true 3 | +++ 4 | 5 | # About KOSS 6 | 7 | * We are a bunch of Open Source enthusiasts, who love to share the culture of OSS. Through events and workshops, we try to share the different aspects of Software Engineering, and onboard folks with the basic understanding and literacy of Software Development. 8 | 9 | * We love to work on new ideas and projects, though we don't promote it from KOSS by default. You can find involvement of KOSS members in MetaKGP, developing on a project which is helpful for the KGP Community. You can also find members who are motivated enough to work on funky ideas and projects, which might range to solve a real-world issue, to create a project for banter, to help out folks learn a new language or framework. Some of us are enthusiastic enough to get involved with admin activities for running Gymkhana smoothly. 10 | 11 | * We are known for conducting technical workshops for sharing knowledge about useful software practices, such as git, python, shell script. You can find more about the events in this [page](/events/git-and-github.md). 12 | 13 | * We inculcate an environment, where each of us work on anything that we might want to learn, and in return you would get fantastic mentors on the subject matter. Want to learn Frontend? Hop on to a call with [xypnox](https://xypnox.com/); Want to learn more about Shell Scripting? [grapheo12](https://grapheo12.in/) is informative to teach you. Infact, each one of us have carved their own specialization and have had their fair share of experience to guide you, so the KOSS members are the goto folks. 14 | 15 | * We value culture over technical prowess; You might be a rockstar developer, and quite adept with your skills, but we love to host people, who are empathic, a team member whom you can trust upon, and whom you can depend on. KOSS provides ample of mentoring to folks who want to curate their skills in a field of their choice, and in return they are expected to pass the baton. People having a sound skills is a bonus, but we value your soft-skills more than your technical knowledge. 16 | 17 | ## What do we do? 18 | 19 | > Thanks for asking this question! This sets up the expectation from KOSS as a society :) 20 | 21 | * We are a college society to spread the culture of Open Source. 22 | 23 | * We conduct workshops and events to share the culture of OSS with the KGP folks. 24 | 25 | * We conduct [KWoC(Kharagpur Winter of Code)](https://kwoc.kossiitkgp.org/) which is a winter long contribution program for new contributors. 26 | 27 | * We conduct Open Source Summit, where we invite people from all around India about their experiences with Open Source Software. 28 | 29 | * Check out our social media links for getting an idea about the content we share with the KGP folks - [Twitter](https://twitter.com/kossiitkgp) [Facebook](https://www.facebook.com/kossiitkgp) [YouTube](https://www.youtube.com/c/KOSSIITKharagpur) 30 | 31 | ## What do we NOT do? 32 | 33 | * We don't coach people to crack GSoC. That is not our main objective as a society. If you want to join KOSS because of this sole reason, you are better suited to ask previous GSoCers about the same. 34 | 35 | * We are not a research based society. We work on Software Development problems, and we use code to ease our approach to achieve our goals. We work on developing projects, which might be helpful for achieving our goals, but all in all, we dont develop projects for the sake of it. We use custom written projects to achieve our goals. 36 | 37 | * Avoid joining KOSS if you want a POR. Effectively, KOSS might not add any value to your resume, if you are looking to join KOSS for the purpose of POR. KOSS helps you to develop good Software Engineering skills and build up the empathy and understanding of Software Engineering. This might not make sense, if your career goals don't match with the above, you would benefit a lot, if you are in for the learning, especially Software Enggineering and OSS. 38 | 39 | * Don't join KOSS if you find the workload quite less. KOSS mostly uses digital medium to catch up with the members, and people might confuse this with low workload. We make sure that the new members are given ample of time to choose and work on their skills of choice, and this involve different amount of workload for everyone. Ultimately, you would be wasting your time in KOSS, if learning the skills of OSS and Software Engineering was something you don't ought to do. We love to keep things relaxed, so that folks work on their skills at their own pace. 40 | 41 | -------------------------------------------------------------------------------- /community/accounts.md: -------------------------------------------------------------------------------- 1 | # Accounts 2 | This document describes all the financial and accounting content related to KOSS. This particular function has to be carried out with the very high standards and utmost sincerity. 3 | 4 | 5 | ## Why does KOSS require money? 6 | 7 | We conduct various workshops and events which require multiple costs like AV Cell booking, room booking, posters, domain hosting, servers, etc. To pay for the costs, the members had donated various sums of money to sustain the society while finding some self-funding source so as to continue the society in perpetuity without much financial strain on it’s individual members. 8 | 9 | 10 | ## What is that self-funding source? 11 | 12 | Currently, we conduct various workshops in an ongoing partnership with KTJ wherein they in turn, agree to donate some money to us. The money which we currently get is sufficient to continue with our expenses. 13 | 14 | 15 | ## What is the goal of receiving donations? 16 | 17 | To get enough money to sustain society and pay for various costs in conducting the events. 18 | 19 | 20 | ## What isn’t the goal of receiving donations? 21 | 22 | The money which we receive should never be used for internal parties/treats. The reason is simple: we don’t want to conduct events because we have the end goal of partying (which happens in majority places). Also, we think it’s a very healthy culture of seniors treating juniors and should continue. 23 | 24 | Side note: If we expect our members to stay the entire day involved in KOSS’ events, workshops, etc then of course, we have to provide food from KOSS’ accounts. Such meals shouldn’t be extravagant, but should be good enough. 25 | 26 | 27 | ## Who maintains this for KOSS? 28 | 29 | A book-keeper is appointed from the 4th year batch (with Dual Degree preferred for the sole reason that they can keep a check even as ex-book-keepers in their final years. 30 | 31 | **Appointment** 32 | The book-keeper is elected by the advisors batch with help from the executive heads. 33 | 34 | **Current book-keeper** 35 | For the current period (2018-2019), Pranit Bauva is the book-keeper. 36 | 37 | **Power** 38 | The book-keeper enjoys no power and merely helps in acting according to executive heads’ decisions. 39 | 40 | **Responsibilities** 41 | 42 | 1. Arrange for donations for self-sustainability 43 | 2. Maintain the GitHub repository kossiitkgp/accounts diligently with high ethical standards 44 | 3. Reinforce the rules/guidelines concerning any accounts related stuff among the whole team 45 | 4. Timely (semester wise and after major event) clearance of dues 46 | 47 | 48 | 49 | # GitHub Repo 50 | 51 | 52 | ## Rules 53 | 1. PR has to be verified by the book-keeper as well as one executive head before being merged 54 | 2. PR should have a photo of the bill with the amount written 55 | 3. PR should contain the transaction id when transferring money from KOSS’ account to someone else for maintaining a record 56 | 57 | -------------------------------------------------------------------------------- /community/code-of-conduct.md: -------------------------------------------------------------------------------- 1 | +++ 2 | 3 | toc=true 4 | 5 | +++ 6 | 7 | 8 | # Workplace Harassment - An informal guide 9 | 10 | ## Some basic fundamentals 11 | 12 | 1. Humans are flawed and make mistakes on a regular basis. 13 | 14 | 2. We don't live in an ideal world, so we are not dealing with ideal scenarios. 15 | 16 | 3. But the above statement doesn't provide wind to the practicality argument. Practicality argument is an exceptionally dangerous proposition in itself. So any time any particular statement is backed up by "being practical", it should take care of few things :- 17 | 1. Being practical means what can be done or is possible in some finite duration. So it should be aggressively progressive in nature and it shouldn't settle on "n" but "n + ∞". We can start from "n" but the vision should be clear to reach "n + ∞" as fast as possible. 18 | 2. It should be “enabler” in nature. 19 | 3. Example :- Just assume some company x is going to sponsor our events for which the whole team has put a lot of efforts, but during that time, a team member y came to know about few events of harassment, so a persuasive member might convince the team that, "it's not practical to reveal these events to public, let's bury it for now". 20 | 21 | 4. Any democratic argument in case of harassment should be thrown out of the window immediately. For example, "9 out of 10 people are okay with this". 22 | 23 | 5. We at times can be irrational due to circumstances sometimes in our control and sometimes beyond our control. 24 | 25 | 6. We don't accept snowflake argument. Some people have thick skin and are borderline stoic, and they think that "I am responsible for my feelings" and on the opposite end of emotional spectrum, are people who think that "You don't get to decide if you hurt someone". We will try to have an inclusive space for both of these people. 26 | 27 | 7. Humans hate to forgive people if forgiving is tough. 28 | 29 | 8. Convincing a human that they are wrong or have done wrong is exceptionally tough. 30 | 31 | 9. All decisions must always be taken wrt the current scenario. Disregarding someone's opinion because of past behavior is wrong. 32 | 33 | 10. Adding "genuinely" prefix in front of sorry doesn't help. 34 | 35 | ## Basic Protocol in case you are harassed/bullied/found something offensive/weird/unacceptable 36 | 37 | Subject -> Who has been harassed/bullied 38 | 39 | Type 1 :- Constitutionally Legal Offense 40 | 41 | In case of sexual harassment, constitutional legal offense comprises of but is not limited to :- 42 | 43 | 1. physical contact and advances 44 | 2. a demand or request for a sexual favour 45 | 3. making sexually coloured remarks 46 | 4. showing pornography 47 | 5. any other unwelcome physical, verbal or non-verbal conduct of sexual nature 48 | 49 | [Ref](https://www.indialegallive.com/special-story/the-legal-perspective-of-mental-harassment/) 50 | 51 | 1. In this case the team is requested not to micromanage. let it go through official channels of college and judiciary and let them deal with it. 52 | 2. Contact [ICC](http://www.iitkgp.ac.in/internal-complaints-committee) 53 | 54 | ### Note 55 | Type 2 :- Everything Else 56 | 57 | 1. If it has happened for the first time, dm the person. And let {pronoun} know that this behaviour is offensive to the subject. If not comfortable confronting then talk to your 1:1 senior, or anyone whom you feel comfortable asking for advice. Do get advice from multiple trusted people before landing on a pathway of action. 58 | 59 | 2. Also, securing evidence of the harassment is important as it substantiates the claims made. 60 | 61 | 3. Post on a public forum that the subject finds this particular behaviour offensive/xyz. Name calling doesn't help. 62 | 4. If there are multiple incidents already, it is more than likely that this will repeat, therefore stricter measures are necessary. 63 | 64 | ## Basic Protocol in case you are accused of harassment/bullying/offending/unacceptable behaviour 65 | 66 | Subject -> Who has been accused 67 | 68 | 1. Well the subject can start by saying sorry, and ensuring that similar behaviour is not repeated in front of the person who has accused the subject "ever". If it's ingrained in the subject’s habit let the accussee know that, it's in your habit you will make sincere effort to decrease the frequency. The subject can take a note and share updates of progress {pronoun} have made on that person's feedback. 69 | 70 | 2. It doesn't matter if the subject’s sorry or change is genuine or fake, as long as it's change for good it's good. 71 | 72 | Note 1 :- Such things are extremely contextual. There could have been a big misunderstanding due to which the other person felt uncomfortable. In those cases both the accusee and accused are requested to handle the situation with utmost humanity and not to scar the other person for life. 73 | 74 | 75 | ## Basic Protocol in case you have noticed harassment. 76 | 77 | 78 | 1. Inform other team members, see about their perspective if they have also witnessed the incident or any other incidents with same accused. 79 | 2. Ask the victim what they want to do about it. Refer to them this guide and let them take the appropriate decisions. 80 | 3. Care should be taken that the incident does not become a means to defame, harass, or trouble the accused until the incident is established and proven. 81 | 4. Proven in a loose sense that there are enough reasons established to conclude that the accused is guilty. 82 | 83 | 84 | 85 | ## Basic Protocol in case you are an executive/advisor and have to take action 86 | 87 | 88 | 1. If it's comes under legal offense, advise the victim to directly deal with the authorities and provide all the necessary support. Time is crucial in such cases and the sooner the matter is pursued for prosecution the better. 89 | 90 | 2. If it doesn't come under legal offense, Inform other team members, see about their perspective if they have also witnessed the incident or any other incidents with same accused. Make sure the discussion doesn't continue indefinitely. 91 | 92 | 3. Mediate the conversation between the victim and the accused. The accused may try gaslighting as a way out 93 | 94 | 4. The matter is over if :- 95 | 1. It is a single incident and the accused is ready for amends 96 | 2. The victim is fine with the amends and doesn't want to take this further 97 | 3. Note - If the victim is not fine with the amends, ask them to suggest what will be fine. If a settlement is not reached, suggest the victim to make the accusation public, if it helps. 98 | 99 | 5. With majority approval of advisors and substantiated proof of the incident is enough to terminate the accused from KOSS. The reason of termination should be made public to stop rumors and misinformation. 100 | 101 | ## What is Considered as Sexual Harassment at Work Place ? 102 | 103 | 104 | ### What workplace at koss includes :- 105 | 106 | 1. Slack workspace 107 | 2. A team outing (similar to an office party) 108 | 3. Events and Event meetups 109 | 110 | ### Note 1 111 | Members of KOSS can always support the victim on other platforms without any intervention from KOSS. However, they should not depict this as a support from the entire society unless anything of that nature is released from the page, the decision of which lies with the Execs and the Advisors. 112 | 113 | ### Note 2 114 | It may happen that A has raised concerns over remarks made by B outside of the KOSS workplace and which do not concern KOSS in anyway, but both A and B happen to be KOSS members, then it is not a situation where KOSS should intervene, I believe. Besides, we are not equipped in any way to deal with such situations. 115 | 116 | Sexual harassment includes many things but is not limited to 117 | 118 | [Ref](https://www.un.org/womenwatch/osagi/pdf/whatissh.pdf) 119 | 120 | | Physical | Verbal | Non-Verbal | 121 | |--------- | ------ | --------- | 122 | | Touching the person's clothing, hair, or body | Referring to an adult as a girl, hunk, doll, babe, or honey | Looking a person up and down (Elevator eyes) | 123 | | Hugging, kissing, patting, or stroking | Whistling at someone, cat calls | Staring at someone | 124 | | Touching or rubbing oneself sexually around another person | Making sexual comments about a person's body , innuendos , Turning work discussions to sexual topics | Blocking a person's path | 125 | | Standing close or brushing up against another person | Telling sexual jokes or stories | Following the person | 126 | | Actual or attempted rape or sexual assault | Asking personal questions about social or sexual life | Giving personal gifts | 127 | | Unwanted deliberate touching, leaning over, cornering, or pinching | Making kissing sounds, howling, and smacking lips | Displaying sexually suggestive visuals | 128 | | | Making sexual comments about a person's clothing, anatomy, or looks | Making sexual gestures with hands or through body movements 129 | | | Repeatedly asking out a person who is not interested | Making facial expressions such as winking, throwing kisses, or licking lips 130 | | | Telling lies or spreading rumors about a person's personal sex life | 131 | | | obscene calling/texting or objectionable messaging | | 132 | 133 | 134 | The point of having this list, is to make people aware that these things can be considered offensive and harassment, by some people. We come from different culture, for example hugging might be quite common in a few culture, but might not be well received by some other culture. So asking “if a person is comfortable” might help in all verbal/non-verbal/physical contact. 135 | 136 | ## What is considered as bullying ? 137 | 138 | [Ref](https://www.stopbullying.gov/bullying/what-is-bullying) 139 | 140 | 1. Verbal bullying, is saying or writing mean things. Verbal bullying includes: 141 | 1. Teasing 142 | 2. Name-calling 143 | 3. Inappropriate sexual comments 144 | 4. Taunting 145 | 5. Threatening to cause harm 146 | 147 | 1. Social bullying, sometimes referred to as relational bullying, involves hurting someone’s reputation or relationships. Social bullying includes: 148 | 149 | 1. Leaving someone out on purpose 150 | 2. Telling other children not to be friends with someone 151 | 3. Spreading rumors about someone 152 | 4. Embarrassing someone in public 153 | 154 | 1. Physical bullying , involves hurting a person’s body or possessions. Physical bullying includes: 155 | 156 | 1. Hitting/kicking/pinching 157 | 2. Spitting 158 | 3. Tripping/pushing 159 | 4. Taking or breaking someone’s things 160 | 5. Making mean or rude hand gestures 161 | 162 | ## Basic Ownership Model 163 | 164 | Subject -> Who has been accused of harassment/bullying 165 | 166 | The actor owns the action and it's consequence like hurting or acting as disabler. You shouldn't blame the affected person for being affected. 167 | 168 | Having empathy and good will for the affected person is great, but the truth is :- 169 | 170 | 1. Just asking/demanding for a thicker skin won't magically generate a thicker skin. 171 | 2. Not every time humans have the energy and need to change. 172 | 173 | So rather than expecting and introducing toxic culture for developing thicker skin, the subject is requested to change themselves temporarily/selectively. It might be general or it can be personalized, but change is necessary. 174 | 175 | ## Status Game 176 | 177 | Try not to play status game by :- 178 | 179 | 1. Taking moral high ground. 180 | 2. Stating the documentation for proving that a person accused of harassment/bullying is wrong and the person proving it, is right. 181 | 3. Putting the other person in a box like, "is a snowflake" , "is an asshole" , "has double standards" 182 | 183 | All of this doesn't solve anything apart from aloofing the person being boxed up. 184 | 185 | ## Nitpicking, Agenda and Bias 186 | 187 | We all have some bias and personal agenda. Nothing wrong. 188 | 189 | But we request the team members to keep their personal agenda/mission and bias to themselves and not let it seep in the public or private workspace of KOSS. Your behaviour in a KOSS workspace should be synonymous to what our organisation stands for. Not to exploit the organisation’s resources and connection to fulfill your personal missions/agenda good or bad. Try not to manipulate our Mission Statement to suit your own agenda, it’s simple, to spread open source”. Now a lot of thing can be indirectly done to spread open source, like distributing food to impoverished child, so that {pronoun} doesn’t die and later come and spread open source, or the below mentioned example, but the thing is there are a lot of things we can do directly to spread open source, that we are not doing, so let’s cover all of them first, then move to deeper and more indirect ways to spread open source. 190 | 191 | Cons, if you follow the above statement line by line :- Classifying someways as direct and someways as indirect is itself filled with bias. Some seemingly indirect ways can bring more people to open source than seemingly direct ways. So the above statement should be taken as guideline, and not limit the team to experiment with new things. This guideline is just there to avoid unnecessary conflicts/misunderstanding/politicisation etc of our workspace and digress too much from our goal. 192 | 193 | Nitpicking replies/comments/reactions based on team member’s gender/sexual preferences/political opinions should be strictly avoided. 194 | 195 | **Example :- A person with a mission to uplift and empower women technocrats can seem, as intentional favouring to achieve and fulfill personal desires. Now thinking in this way, my intentions are good, so it doesn’t matter what other people think about me, is not acceptable. It does matter and your actions affect the whole organisation. It’s a good cause, but the way and place might not be appropriate.** -------------------------------------------------------------------------------- /community/event-checklist.md: -------------------------------------------------------------------------------- 1 | toc=true 2 | 3 | +++ 4 | 5 | # 1. Logistics - Before the Workshop 6 | 7 | ✔️ Decide the **_date and time_** of the event as per the convenience of speakers and audience. Conducting **_events during exams_** or some other important event might **_not be a good idea_** in general. Checking **_academic calendar_** and other events in KGP is suggested. 8 | 9 | ✔️ Publicize the event at least **_2 or 3_** days before the workshop. Publicizing earlier will fade away the event info from memory and publicizing late will be difficult for the audience to plan for. 10 | 11 | ✔️ Complete [room and AV cell booking](../events/room-booking.md) _at least_ **2 weeks** before the workshop. 12 | 13 | ✔️ Share the Post on Facebook, Twitter and Linkedin via KOSS Account. 14 | 15 | ✔️ Speakers should be **_decided atleast a week_** before the workshop, giving them enough time to prepare. 16 | 17 | ✔️ It is important to have _atleast two_ backup speakers for each speaker.(One for the speaker, one for the backup speaker) 18 | 19 | ✔️ Speakers of the event should have enough practical experience with the topic. The experience is necessary so that speaker can convey the content in the simplest way and clear doubts. 20 | 21 | ✔️ It is highly recommended that the Slides for the event are made from scratch by the speaker. Preparing from scratch will add creativity and newness to the content. New and simpler ways to present a topic might come out. Also... 22 | 23 | ​ 🗸 Feel free to look up at previous slides at [kossiitkgp/slides](https://github.com/kossiitkgp/slides) repo for inspiration. 24 | 25 | ​ 🗸 Make sure that something important that has been covered in the past doesn't gets removed. 26 | 27 | ​ 🗸 Feel free to remove or edit stuff if you ever feel some part of the content is unnecessary and irrelevant, after discussing with team mates. 28 | 29 | ✔️ Make sure to take feedback on the slides(content) from other members of KOSS. It is suggested to have the discussion over a meet to discuss things like potential queries from audience, thinking of ways to simplify content. 30 | 31 | ✔️ Refer [kossiitkgp/mistakes](https://github.com/kossiitkgp/mistakes) repository to get an idea of what sought of things can go wrong. 32 | 33 | ✔️ It is a good idea to record the event(offline/online) for the sake of posterity. 34 | 35 | ✔️ Make a Github repo for the workshop with name as event name and year which contains - installation instructions, slides, references, recording and others. (For example refer - [1](https://github.com/kossiitkgp/git-and-github-workshop-2020), [2](https://github.com/kossiitkgp/REST-APIs-in-Flask-Workshop-2021), [3](https://github.com/kossiitkgp/Linux-Shell-Vim-Workshop-2021)) 36 | 37 | ## 1.1 Internal 38 | 39 | - Keep in touch regularly with other team mates on updates regarding the event. Regular communication on #events channel is suggested. 40 | - Meet regularly to discuss stuff. It is advisable to send mail invites even for a smaller meet, to avoid procrastination. 41 | 42 | - **Making the workshop interactive**: It is always a good thing to keep the workshop interactive. If the workshop is conducted offline, we can have members of KOSS help people personally with hands on during the workshop and clear doubts more personally. But during an online workshop, this is not possible. So for sake of interaction, the speakers can encourage the audience to share the screen to show the work. This acts as validation and also helps the rest of the audience. Asking the audience to share their screen in case of difficulties should also be encouraged. However note that,**do not force the audience to share their screen for sake of interaction. It has be voluntary and audience should not feel uncomfortable through such actions.** 43 | 44 | # 2. Technicalities - Workshop content 45 | 46 | ## 2.1 How to decide the Topic for the workshop 47 | 48 | - Make sure that the topic adds value to the community. The topic doesn't have to be trendy or in vogue. 49 | - Atleast a couple of members at KOSS should have enough practical experience to speak about the topic. The practical experience is helpful in organizing and delivering the contents of the workshop in a simple and intutive way. Otherwise, it would lead to just reproducing the content online, which is less valuable. 50 | 51 | ## 2.2 How to decide the content of the workshop 52 | 53 | Make sure that the content adds a practical value to the audience. It might be tempting to add bits of cool jargon or theoretically detailed stuff to impress. But it is not recommended. For every slide, ask- Is this something that adds practical value. Will knowing or not knowing a particular thing affect the practical understanding of the topic. For example, consider explaining the idea of Merkel Tree in git, it might not be necessary to include the explanation of Merkel tree. As someone getting started with git, it is more important to practically understand staging area, branching, commits, sending a PR, pushing and pulling. When we get into details like Merkel Tree, audience might lose track of the event and lose interest. However, for the curious audience, it is a good idea to include such things at the end of the workshop, and provide further resources to explore more. 54 | 55 | During the core period of the workshop, make sure that they get a **practical hands on experience**(which is what they have come for, otherwise they could have learnt it on YouTube too!) 56 | 57 | Make sure to give enough time to cover the queries and concerns of the audience during the workshop.(without queries and interaction, the workshop would not differ from a YouTube Tutorial) 58 | 59 | ## 2.3 How to organize or approach content: 60 | 61 | - **2.3.1 Introduction:** It is a good idea to tell the audience the following things: 62 | 63 | - What they should take away from the workshop. For example, if it is git workshop, convey that by the end of the workshop they will be comfortable to track their project using git and know how to send a Pull Request properly to a open source repository on Github. 64 | 65 | - Give the audience about how the flow of workshop would be. For example... 66 | 67 | - While hands on, asking them to do them along with the speaker 68 | - There will be small doubt sessions periodically **or** may be if the speaker is comfortable, he/she may ask the audience to interrupt in middle and ask the query. It is a good idea to take breaks after each [microcentury](https://susam.in/blog/microcentury/) 69 | - It is a good idea to warn the audience if there is a long strech of theoretical discussion for the next few minutes. 70 | 71 | - **2.3.2 Introducing a new topic**: If you are introducing any new topic, it is suggested to try either of the two methods - 72 | 73 | - **First principles approach**: Introducing the topic from the ground up. Don't just bring up a word and say, **_"we are going to learn about this X topic now"_**. Introduce a practical situation to explain why something of this sort is necessary. For example, in git consider the topic "branching". Introduce a problem in the beginning, where git branching is a super-useful solution. This will help the audience grasp the idea better. 74 | 75 | - **Using Analogy**: It is always a useful thing to give a analogy with something which people already know. For example, in git consider the idea of staging area. The staging area is [generally difficult to grasp](https://github.com/kossiitkgp/mistakes/blob/master/git-workshop.md#git-workshop-2018) for someone new to git. To explain this, one can use "shopping in a mall" analogy. 76 | 77 | - Selecting items from the rack <-> Making changes in the files 78 | 79 | - Adding items in the shopping cart <-> Adding files in the staging area using `git add ` 80 | 81 | - Billing at the counter <-> Commiting the changes 82 | 83 | The above analogy was inspired from a [stack exchange answer by Spoike](https://softwareengineering.stackexchange.com/questions/119782/what-does-stage-mean-in-git), Later modified by @Shankusu993 . Good analogies can be found by searching for intuitive explanations for the topic on web and also by brainstorming with the team. The above analogy was a result of both! 84 | 85 | **Caution**: **Make sure to be aware of the consequences of the analogy used. Sometimes analogies can be misguiding. In that case, it is suggested to chose a different analogy. Alternatively, you can also warn the audience that the crafted analogy does not hold for further ideas. The analogy is only helpful for this concept.** 86 | 87 | # 3. Logistics - After workshop 88 | 89 | ✔️ Upload the slides and reference in the GitHub repo made for the workshop. 90 | 91 | ✔️ Once the audience has learned the basics from our workshop, we should encourage the curious ones to explore more advanced and interesting topics on their own. Hence for such people, update further reading material or links to explore more regarding the topic. 92 | 93 | ✔️ Share the updated repo's link along with a thanks for the audience. It is a good idea if the post explains the contents of the repo. A Facebook post after the workshop serves the purpose (For example, refer - [1](https://i.imgur.com/IoZsw6r.png),[2](https://i.imgur.com/fHflDQ2.png)). 94 | 95 | ✔️ If the event is recorded then upload it on youtube via KOSS account and share its link along with workshop's repo link. 96 | 97 | ✔️ For sake of posterity, update the [kossiitkgp/slides](kossiitkgp/slides) repo 98 | 99 | ✔️ Update the [kossiitkgp/mistakes](https://github.com/kossiitkgp/mistakes) repository 100 | -------------------------------------------------------------------------------- /community/governance-review-week.md: -------------------------------------------------------------------------------- 1 | +++ 2 | toc=true 3 | +++ 4 | 5 | # Governance Review Week 6 | 7 | ## What is it? 8 | 9 | It is a week dedicated to the Governance of KOSS. 10 | 11 | Our intention behind organizing the Governance Review Week is to help the core team members measure their level of involvement in KOSS. The week also promotes open discussions between Seniors and the Core team members. We want each one of our members to be frank with their batchmates as well as seniors in sharing their opinions and perspective on every aspect of KOSS. 12 | 13 | We also review how KOSS performed as a team in the past year. We identify our problems and discuss solutions. We want to make sure we eliminate all forms of toxicity from KOSS (It can be habits of how we do things, or some Core Team members themselves.) 14 | 15 | ## What is the structure and timeline? 16 | 17 | We physically meet for 3-5 days for 3-4 hours each day. We put up few questions in advance and the Core Team Members have to think and give their answers or their take on the subject. All the second years individually speak for a few minutes. The time limit is decided and followed. We later discuss the answers given by the CTMs. The members send their answers on the Google Group thread of the day. The sessions are recorded and put up on our archives. 18 | 19 | ## What happens after this week? 20 | 21 | Executive Heads discuss the involvement and membership of each Core Team member. If they find someone not being a good fit to continue, this is the time when the team is updated and they are laid off (See [Onboarding/Offboarding](/community/onboarding-offboarding.md)). 22 | 23 | After the week, Core Team members become the new Executive Heads and Executive Members (See [Governance](/community/governance.md)), quickly followed by an Introductory Seminar and the [Selection of new members](/events/freshers-selection.md). 24 | 25 | A new version of KOSS Documentation is released. It is suggested to scrutiny everything which is written over here. Detailed changelog should be published which answers, "What changed and Why?", "What things worked out really well?", "What more should be written?", etc. Alumni of KOSS will receive the changelog via email, and it will be published in the repository as well. 26 | 27 | 28 | ## Why do we do this? 29 | 30 | - Evaluation. We want Core team members to review their year and contributions to KOSS 31 | - Executive Heads want to understand the priorities and values of the new batch. They form the questions to do so. 32 | - This is a great time to know and identify potential Executive Heads on an individual level. 33 | - Self-awareness of all the members. 34 | - Questioning the principles of KOSS. We discuss and make serious policy changes to how things are done. 35 | 36 | ## Archives 37 | 38 | ### 2019 39 | 40 | **Who were the CTMs?** 41 | 42 | Class of 2017 43 | 44 | **What were the dates, times and venues?** 45 | 46 | | Day | Date | Time | Venue | 47 | |-------|--------------------|---------------------|------------------------| 48 | | Day 1 | Jan 29, 2019 (Tue) | 9:30 pm (3.5 hours) | JCB Laboratory Complex | 49 | | Day 2 | Jan 30, 2019 (Wed) | 9:00 pm (3 hours) | JCB Laboratory Complex | 50 | | Day 3 | Feb 01, 2019 (Fri) | 6:15 pm (2.5 hours) | Nehru museum | 51 | 52 | 53 | **Link any Photos/Videos/Audios of the days** 54 | (Unlisted videos) https://www.youtube.com/playlist?list=PLvR6QxlsxrWqHfVWbilcBcBiSYWqldEXQ 55 | 56 | **What were the questions/topics day wise? (Link to the answers/Google Group thread)** 57 | 58 | Day 1 - https://groups.google.com/d/msg/kossiitkgp/wFGCjKuoM-k/JK91jCVWFgAJ 59 | 60 | ``` 61 | - Question 1 (1.5 mins) 62 | - There were multiple events/workshops organized internally and externally. Share your “wins-list”! Here is your chance to show-off your contributions made to KOSS. Do not underestimate any kind of contribution. Be precise and exhaustive. 63 | 64 | 65 | - Question 2 (4 mins) 66 | - We at KOSS have noticed that we have a developed a toxic culture of delaying the work and tasks to the last moment. Though some tasks and timelines are planned, they are not executed properly. 67 | - What do you think is the root cause of this issue? 68 | - As an executive, what steps would you take to eliminate such a culture? 69 | - Would you prefer distributing workload with deadlines to each member or rather have a committed sense of ownership within the group and have people take tasks on their own? 70 | 71 | 72 | - Question 3 (2 mins) 73 | - Any organization is driven by a strong bonding nature between the members. 74 | - Is there a communication gap in KOSS? Mention evidence if you can recall. 75 | - Think of an idea to overcome it? 76 | - How will you increase the bonding among the new members and as well as the entire juniors and executives batch? 77 | ``` 78 | 79 | Day 2 - https://groups.google.com/d/msg/kossiitkgp/DmO7K-CZnOQ/UTfVzASxFgAJ 80 | 81 | ``` 82 | - Question 1 (4 mins) 83 | - From what you have observed in your own batch, what are the qualities/characteristics you will be looking forward from the incoming batch? How would you be the judging these criteria? 84 | - From this year we have decided to go for forms for the first round. (Similar to what GitHub and other tech companies do) 85 | - What are the questions that you would like to add there? How are you going to judge based on these questions? 86 | - What are some good red-flags would you use to remove false positives? 87 | - How would you plan the interviews and panel (size, composition)? 88 | - What should be the ideal size of the batch? 89 | - How do you present KOSS to them i.e. value they will gain from KOSS? 90 | 91 | 92 | - Any other comments on selection apart from what we discussed? 93 | 94 | 95 | - Question 2 ( 3 mins) 96 | - Why do you think these events were started in the first place? 97 | - Suggest one new event(workshop/seminar/different genre) that we should conduct in the upcoming year. 98 | - Why do you want this to be executed? 99 | - Give a brief overview of how would you go about organizing it as the Executive responsible for the event. 100 | ``` 101 | 102 | Day 3 - https://groups.google.com/d/msg/kossiitkgp/-t4l9WdJYhs/HlS8UpzCFwAJ 103 | 104 | ``` 105 | - Question 1 [3 mins] 106 | - How was your year working in KOSS? 107 | - Mention at least 3 things you learned at KOSS. 108 | - Which event(s) did you enjoy? 109 | - Think about the time when you joined KOSS. Which of your expectations have been met and which ones have not, yet? What were some of the unexpected things you overwhelmingly enjoyed, which you hadn't expected? 110 | - Question 2 [2 mins] 111 | - Mention one thing that you want to change about KOSS (be it the culture, the hierarchy structure, the management or anything that you feel will be harmful in the long run)? 112 | 113 | 114 | - Question 3 [2 mins] 115 | - Is KOSS different from other societies? Why/Why not? 116 | - How is KOSS helpful to you? ( We try to spread open source ideas, etc. for the people in campus but what about you? ) 117 | ``` 118 | 119 | --- 120 | 121 | ### 2018 122 | 123 | **Who were the CTMs?** 124 | 125 | Class of 2016 126 | 127 | **What were the dates, time and venues?** 128 | 129 | | Day | Date | Time | Venue | 130 | |-------|-------------------|---------------------|----------------------------------| 131 | | Day 1 | Feb 4, 2018 (Sun) | 9:00 PM (3 hours) | Nehru museum | 132 | | Day 2 | Feb 5, 2018 (Mon) | 9:00 PM (2.5 hours) | Nehru museum | 133 | | Day 3 | Feb 6, 2018 (Tue) | 9:00 PM (2 hours) | Nehru museum | 134 | | Day 4 | Feb 9, 2018 (Fri) | 9:00 PM (4 hours) | Vikramshila garden (Rao canteen) | 135 | 136 | **Link any Photos/Videos/Audios of the day** 137 | 138 | Unlisted videos/playlist 139 | 140 | https://www.youtube.com/watch?v=c4r4nk1QKdQ&&list=PLzumvJj1-3nB-p7awDUJ9kMz9--fkDbIs 141 | 142 | **What were the questions/topics day wise? (Link to the answers/Google Group thread)** 143 | 144 | Day 1: https://groups.google.com/d/msg/kossiitkgp/WxBNzdCBb5Y/U0cCf-mTBwAJ 145 | 146 | ``` 147 | - Question 1 (4 mins) 148 | - We conducted numerous flagship events/seminars during the past year, e.g., KWoC, Summit, Git workshop, Dual boot best, GSoC seminar. 149 | - Why do you think these events were started in the first place? 150 | - What order would you suggest for the organization of the Autumn Sem events? Why? 151 | - Why and how do you think new ideas come up? How would you, as an Executive, promote innovation of ideas in the team? 152 | - Suggest one new event(workshop/seminar/different genre) that we should conduct in the upcoming year. 153 | - Why do you want this to be executed? 154 | - Give a brief overview of how would you go about organizing it as the Executive responsible for the event. 155 | 156 | 157 | - Question 2 (2 mins) 158 | - At KOSS, we believe that before organizing any event, it’s important to discuss the pros and cons. The ability to listen to others and being humble about your idea is of prime importance. 159 | - We encourage people to share their passion for technologies with the team. Thus, we appreciate transcending the “senior”-”junior” hierarchies (as long as its mutually respectable) in order to share your thoughts and opinions. At the same time, it is required of every member to take ownership of their work and readily accept their mistakes. 160 | - Share an instance when you took a stance about something you are passionate about. 161 | - As a “senior”, how would you promote this culture among the team, especially the newcomers? 162 | ``` 163 | 164 | Day 2: https://groups.google.com/d/msg/kossiitkgp/WxBNzdCBb5Y/XtzHMunyBwAJ 165 | 166 | ``` 167 | - Question 1: (3 mins) 168 | - The ability to communicate clearly with the team members forms the basis of any successful organization. We created the KOSS Slack Workspace to facilitate everyone to share their opinions with others and stay connected. 169 | - What’s your take on current state of intra-group communications in KOSS (i.e. Senior - Executive, Executive - Juniors, Senior - Junior)? (1 min) 170 | - How do you communicate with others in KOSS? (20 sec each) 171 | - Batchmates 172 | - Executives 173 | - Seniors 174 | - According to you, what should one post publicly on channels and what should be discussed in private or DMs? (1 min) 175 | 176 | 177 | - Question 2: (2 mins) 178 | - Let’s now focus on our hierarchy and what should be expected of the different batches in KOSS. (30 sec each) 179 | 180 | 181 | - Ideally, what should be the role of Executive Heads? 182 | - What should be the task of Juniors/newcomers? 183 | - What should be governed by the Seniors? 184 | - How do you get the team members involved in the proceedings of KOSS? 185 | 186 | Question 3: (1 min) 187 | 188 | 189 | - Do you agree that the level of comfort between “seniors” and Executives is more than that between “juniors” and (seniors + Executives)? 190 | - If so: 191 | - Why do you think it exists? 192 | - One suggestion on how we can bridge this gap. 193 | ``` 194 | 195 | Day 3: https://groups.google.com/d/msg/kossiitkgp/H1A5SG8RV1g/LKLGdHpACAAJ 196 | 197 | ``` 198 | - Question 1: (2 mins) 199 | 1. What are the qualities and experiences do you look for while inducting first-year students? 200 | 2. What are some good red-flags would you use to remove false positives? 201 | 3. How do you present KOSS to them i.e. how would KOSS generate value for them? 202 | Mention the reasons for each of your answers. 203 | 204 | 205 | - Question 2: (2 mins) How do you plan to spend the year with them, especially the first few months? How should we increase the communication between new people and the old members? Does having a room help? What are some crucial problems and how can we solve them? One example is the inertia to join Slack. 206 | 207 | 208 | - One important note: 209 | - It's totally unethical for us to not listen to the person who is speaking, does not matter if they are our senior, batchmate or junior. If we do so, it's a waste of none other than our time. We should prioritize listening over speaking. 210 | ``` 211 | 212 | Day 4: https://groups.google.com/d/msg/kossiitkgp/RHlFh8Cv8po/eQNh_geTBAAJ 213 | 214 | ``` 215 | - Question 1: (4 mins) 216 | - How was your year working in KOSS? 217 | 1. What activities did you work on? 218 | 2. Mention at least 3 things you learned at KOSS. 219 | 3. Which event(s) did you enjoy? 220 | 4. How did you help in organizing Open Source Summit? 221 | 5. Do you think your colleagues worked more than you for KWoC/Summit? How could you have helped them? 222 | 6. Think about the time when you joined KOSS. Which of your expectations have been met and which ones have not, yet? What were some of the unexpected things you overwhelmingly enjoyed, which you hadn’t expected? 223 | 224 | 225 | - Question 2: (2 mins) 226 | - Do you think KOSS has any toxic element (event/culture/person) which you think might harm in the long run? Why do you think so? What’s your proposal to deal with it? 227 | ``` 228 | -------------------------------------------------------------------------------- /community/governance.md: -------------------------------------------------------------------------------- 1 | +++ 2 | toc=true 3 | +++ 4 | 5 | # Governance 6 | 7 | ## Hierarchy 8 | 9 | * **Executive Heads**: The public face, managers and the decision makers. 10 | * Rest - 11 | * **Core Team Members**: Freshers batch. (< 1 year of experience) 12 | * **Advisors**: People who have been an Executive member in the past and are still on the campus. 13 | * **Alumni**: People who have graduated but were Executives when on campus. 14 | 15 | Permanent membership of KOSS mandates serving one year as an Executive. But if advisors mutually agree that any particular human shouldn't be advisor due to several reasons like fundamentals which includes work ethics and style(for example aristocratic), wrong inheritance of values(how things work, why things are the way they are etc) of being in KOSS, what values they are imparting/spreading to their junior and their batchmate and how much they are aligned with KOSS work culture or their contribution as Executive, then they can remove that particular human. Ref [ISSUE-16](https://github.com/kossiitkgp/docs/issues/16) 16 | 17 | 18 | ## The Story 19 | 20 | Members join KOSS in their first year as Core Team members. They spend their time learning technologies, as well as working on raising the awareness of Open Source. At the end of their second year, they take up the role of Executive Heads and Executive Members after a rigorous [Governance Review Week](/community/governance-review-week.md). The former Executive Heads and Advisors decide whether a CTM will become an Executive Head or an Executive Member. (See [Onboarding/Offboarding](/community/onboarding-offboarding.md)). After serving another year, they pass on the baton to the next batch, and they become Advisors while staying on the campus. They actively take part in the discussions, events, and seminars as per their skills and expertise. They graduate to become KOSS Alumni, the role of which is undecided yet. 21 | 22 | ## The policy of KOSS membership 23 | 24 | We recruit UG 1st years in the team, preferably after they have spent one semester on the campus. We can also recruit any 2nd year in their third semester, based on recommendations by the members. 25 | 26 | In the spring semester of Core Team members, they go through a Governance week discussion and finally become the new Executives (Heads and Members). Former Executives should carefully offboard members who are not a good fit for the upcoming Executive batch. Every single individual should have a net positive impact on the team. See [Onboarding/Offboarding](/community/onboarding-offboarding.md) for more detail. 27 | 28 | 29 | ## Detailed Role Descriptions 30 | ### 1. Executives 31 | 32 | > Members in their late second and early third year 33 | 34 | ### 1.1 Executive Heads 35 | 36 | Executive Heads are de facto managers of KOSS. They have complete authority to make decisions and take up initiatives. They manage KOSS public relations on Emails and Social Media. Executive Heads are responsible for inducting new members as well as pruning anyone’s membership as they unanimously decide. In short, Executive Heads are KOSS. 37 | 38 | Executive Heads decide the timeline of KOSS. They call the full-body general meetings. Executive Heads lead all the meetings and events unless they explicitly request anyone else to do so. 39 | 40 | **All** of KOSS meetings have to be conducted in the knowledge of an Executive Head. Executive Heads have to take steps to prevent any abuse of power or harassment. 41 | 42 | Executive Heads regularly consult with the Advisors. They must do it before introducing any change with high impact. 43 | 44 | They approve Pull Requests to https://github.com/kossiitkgp/accounts. 45 | 46 | ### ~~1.2 Executive Members~~ 47 | 48 | ~~Executive Members do not take the lead but have experience in working with KOSS and the Executive Heads. Their primary objectives are:~~ 49 | 50 | - ~~Involving Core Team members through projects/hackathons to improve their skills~~ 51 | - ~~Supporting Executive Heads when necessary~~ 52 | 53 | ~~They act as resources of KOSS. They offer their suggestions constantly throughout the year.~~ 54 | 55 | ~~They do not make any decision for KOSS without consulting the Executive Heads, or unless told to do so.~~ 56 | 57 | We had a physical meeting in Kgp campus regarding this as well. It was mutually agreed that this should be removed. Reasons are mentioned in [ISSUE-15](https://github.com/kossiitkgp/docs/issues/15) 58 | ### 2. Core Team members 59 | 60 | > Members in their late first and early second year 61 | 62 | Core Team members always represent the next generation of KOSS and FOSS culture at IIT Kharagpur. They actively volunteer to learn and conduct events, workshops, classes, etc. CTMs also learn how to work in a team. “Community is more important than Code,” and the core team should take this seriously. 63 | 64 | At the end of the session, there is a week-long discussion with the Core Team members where they put their ideas forward on topics such as ‘Events,’ ‘Community Standards,’ ‘New hires,’ ‘Meetings and Communications’, etc. After these discussions, the former Executive Heads select the new Executive Heads and Executive Members and terminate the membership of people who are not a cultural fit to work with the Executives. 65 | 66 | ### 3. Advisors 67 | 68 | > Members who have been an Executive before and are still on campus. Late third year onwards. 69 | 70 | Advisors, in general, have more technical experience. They have seen a lot of KOSS, and the members should use their experience as a resource. They actively suggest better technologies to be used in KOSS. They also make sure the Executive Heads are not over-prioritizing anything and are relaxed. They continuously take updates from the Executive Heads about what is going in KOSS. They intervene when asked by an Executive to resolve any conflict. They can also lead meetings if Executive Heads do not object. 71 | 72 | One of the Advisors acts as the Treasurer of KOSS and oversees the finances. See [Accounts](/community/accounts.md). 73 | 74 | ### 4. Alumni 75 | 76 | “Members who have graduated from KGP” 77 | 78 | The role has no formal duties, as of now. 79 | 80 | 81 | ## Guidelines 82 | 83 | ### Guidelines for Executive Heads - 84 | 85 | * Do not miss a meeting unless extremely required (health or out of station). Your lack of involvement will psychologically disolve your responsibilities. Schedule meetings according to the availability of all the Executive Heads. 86 | * Be in sync among yourselves. Frequently meet with each other. You will build an amazing friendship with this, which will remain beyond KOSS. 87 | * Respect time of your fellow Executives and Juniors. Do not slack off. 88 | * Always have a lump-sum timeline for events and internal workshops for a particular semester (or year). Core Team members are an essential part of overall execution, so not having a timeline puts them at blindside, and they cannot manage their time. 89 | * Your Core Team Members are your KGP juniors as well. Make sure they prioritize their mental and physical health. 90 | * Follow "Survival first" rule. You need to ensure that your Core Team members have learnt enough to continue in KOSS. You can prioritize this over conducting a fancy workshop. 91 | * Make sure KOSS is a sexually and emotionally non-hostile place to work. Importance of this point is definitely not determined by where it is placed. 92 | * Build strong connections with your Core Team members. Have regular 1:1s. Prefer Meetings and Calls over Slack and Email. 93 | * Keep your Executive Members as involved as possible. 94 | 95 | ### ~~Guidelines for Executive Members -~~ 96 | 97 | * ~~Give Executive Heads their freedom. Do not interrupt or hinder their momentum of doing things.~~ 98 | * ~~Offer suggestions whenever you feel like it.~~ 99 | * ~~Come to meetings. Build relations with Core Team Members. Be active on Slack.~~ 100 | 101 | ### Guidelines for Core Team Members - 102 | 103 | * We believe in self-motivation and a sense of ownership. Try to take initiatives and tasks on your own. 104 | * Make sure you are active within the community. Reach out to your batchmates and seniors once in a while. Discuss stuff with people, or you might end up losing interest. 105 | * Communication skills are vital for any line of work. Practice public speaking and teaching as often as possible. Try to get over your stage fear (if you have one). 106 | * There will always be people who do certain things better than you in one or more aspect. Don’t get intimidated by this. Instead, try to get the most of out it. Knowledge-sharing is how we as individuals grow. 107 | 108 | ### Guidelines for Advisors - 109 | 110 | Dear fellow advisors, 111 | 112 | It’s very easy to be the grumpy old fellows pointing out mistakes in others’ work and it’s quite tempting since our brain mostly favors short-term rewards. The real challenge is to enable people to improve and change themselves as well as the organization. Hiring the right people and steering them in a good direction should be the aim of an advisor. 113 | 114 | While the Execs are mostly involved in doing a lot of ground work, advisors can really think about the overall organization and how they can improve it (since we aren’t caught up in day to day shit). 115 | 116 | (Bauva’s Theory) Enablers vs Disablers: 117 | Enablers are the people that enable an organization to do good while disablers are exactly the opposite. Enablers are the people who can with their energy and attitude allow more people to collaborate more productively. Enablers trust the people they recruit to do their job (this has got to do a lot with having hope and faith that we have the right strategy for recruiting since without it it’s impossible to have that confidence) and teach them. Disablers don’t trust the people they recruit and curse them for their mistakes (realize that everyone makes mistakes, and it’s more important that you learn from them). An advisor should remember that every interaction is important and after you have “enabled” someone, you have set them on a good path and vice versa. 118 | 119 | Advisors should aim for being enablers in KOSS and avoid being disablers. 120 | 121 | What an advisor should aim for: 122 | 123 | 1. Trust the team that you have hand-picked (the most important one) 124 | 2. Motivate the team 125 | 3. Create reliable systems and process (like `docs` or `mistakes` repo) that reduce systematic errors 126 | 4. Provide valuable experiences 127 | 5. Asking Execs the reason behind their actions and thorough cross-questioning 128 | 6. Help people learn 129 | 7. Set the culture 130 | 8. Set guidelines and goals 131 | 9. Appreciate and shower praises for the good work 132 | 133 | It’s also important to remember how we (advisors) felt when we were in our 2nd and 3rd years. Campus life is **really hard** and it takes a toll on the best of us. Remember that Execs & CTM have their own life with their own problems which they want to solve to achieve their own goals. There are many things obvious for us right now and we know what to focus on and what to not focus on. So the next time, if some junior comes up to you and says, “Kal test/assignment/lab hai, toh kaam nahi hoga” don’t starting whining about how you didn’t give a fuck about it when you were young and wild (either they won’t care or they will mistake you for being reckless). “Humare bhi dusra kaam hota hai per phir bhi hum kaam karte hai” isn’t exactly the sentence that would motivate someone. Instead try to find a solution where you solve his/her issue along without hampering the work to be done. 134 | 135 | 136 | -------------------------------------------------------------------------------- /community/onboarding-offboarding.md: -------------------------------------------------------------------------------- 1 | +++ 2 | toc=true 3 | +++ 4 | 5 | # Onboarding/Offboarding 6 | 7 | ## How to onboard someone in KOSS? 8 | 1. Add them to the “Newbies” GitHub team. 9 | 1. Add them to the kossiitkgp@ Google Group. Check the delivery settings. Anyone can ask to join using this link https://groups.google.com/g/kossiitkgp 10 | 1. Add them to the Slack. Make them install the Slack desktop and mobile apps and enable notifications to not miss out any important updates. 11 | 1. Create a private Slack channel named `koss-xx` (where `xx` are the last two digits of the batch year) and all new members to it. Leave the channel once all new members join. 12 | 1. Create a private Slack channel named `a-b-c-d` where each of the letters represents the full name of one member of each of the four batches on campus. Add all on-campus KOSS members(CTMs + Executives + Advisors) to this channel. This will be used as the main medium of communication for shop talk. 13 | 1. Add their contact details on https://github.com/kossiitkgp/secrets. 14 | 1. Update the [Bhattu bot](https://github.com/kossiitkgp/bhattu) with the new batch's Slack accounts. 15 | 1. Assign their 1:1 group. 16 | 1. Add their name to the website. 17 | 1. Give access to KOSS’s facebook page. 18 | 1. Make them store numbers of everyone in team using the automatically generated VCFs in the secrets repository. 19 | 1. Ask them to create their batch's private Whatsapp group and add it to the "Kossverse" community. 20 | 1. Create a Whatsapp group with the Executives + CTMs and name it `KOSS XX` where `XX` is the sum of the last two digits of the batch years of the executives and CTMs. Eg: Batch of '21 and batch of '22 will have a whatsapp group named `KOSS 43`. (Credits to [@rakaar](https://github.com/rakaar) for the naming scheme). 21 | 1. Create a Whatsapp group with all the on-campus advisors (Last two batches, B.Tech and Dual), Executives, and CTMs, and name it `KOSS XX` where `XX` is the sum of the last two digits of their batch years. 22 | 1. Add both of the above groups to the `Kossverse` Whatsapp community. 23 | 1. The purpose of the Whatsapp groups is promotions, bakaar, and motivation to use Slack. It will be an unofficial platform for communcation. This should be made clear to the new members and they should be encouraged to use Slack as the main medium of communication. 24 | 25 | ## How to re-designate Core Team Members as Executives? 26 | 1. Make all Executives the Admins of Slack workspace and add them to the `#emails` channel. 27 | 1. Make all new executives enable two-factor authentication on their Github accounts before proceeding with the further steps. The following steps give access to crucial organization repositories and settings. 28 | 1. Add all Executives to the `Admins` team on GitHub org. Remove them from the `Newbies` team. 29 | 1. Replace all members of the `Executives` team on the Github org with the new executives. 30 | 1. Ask an Owner of kossiitkgp GitHub org to change role of Executives as `Owners`. 31 | 1. Make Executives the Managers of the Google Group. 32 | 1. [Transfer access](./socials.md#transferring-access) of Social media accounts. 33 | 1. Release the names from blog/facebook page. 34 | 1. Update the “Members” section on the website. 35 | 1. Make a few randomly chosen executives admins of the "Kossverse" Whatsapp community while removing the graduating admins. There is a limit of 20 admins. 36 | 37 | ## How to re-designate Executives as Advisors? 38 | 1. Make all Advisors the Owners of Slack workspace. 39 | 1. Make all Advisors the Owners of the Google Group. 40 | 1. Add all new Advisors to the `Advisors` team on GitHub and move graduated advisors to the `Alumni` team. 41 | 1. Update Contacts README on `kossiitkgp/secrets`. 42 | 1. Update the “Members” section on the website. 43 | 44 | ## How to offboard someone from KOSS? 45 | 1. Remove them from the GitHub organization. 46 | 1. Disable their account on Slack (Contact an owner if they are admin). 47 | 1. Remove them from the Google group (Contact owners of group). 48 | 1. Update the Contacts on https://github.com/kossiitkgp/secrets. 49 | 1. Update the “Members” section on the website - https://kossiitkgp.org. 50 | 1. Remove access to KOSS’ facebook page. 51 | 1. Remove their access to KOSS gsuite account if they have access. 52 | 1. Change any passwords they had access to and update the [passwords](https://github.com/kossiitkgp/passwords) repository. Notify the password change on Slack. 53 | 1. [Revoke acess](./socials.md#revoking-access-for-offboarding) from social media accounts. 54 | 1. Remove them from the "Kossverse" Whatsapp community and any official KOSS Whatsapp groups. 55 | 56 | ## Why do we lay off some members? What are the reasons? 57 | 58 | A bad influence justifies bad turn of events in the future. They will recruit similar kind of people. New Core Team Members will start following them. Hence, we can not be passive about the membership of a CTM. We have to make sure we purge any unwanted behavior in time. Hence, it is important that we keep the doors open for uncompatible individuals in order to preserve KOSS culture and essence. 59 | 60 | We totally understand that it is natural for folks for having change of plans after 2 years in KGP, and we should be really clear about the fact that we want motivated/passionate folks, who can stick for KOSS and are enthusiastic/interested in Open Source. Folks who are not aligned with this thought, would be a poor addition to the executives/advisors, so it makes sense for keeping like minded people in the batch. Brings down the moral, and makes it difficult to believe in the responsibilities, because they can always find a person, who is not having same level of commitment. 61 | 62 | 1. If they do not align with our vision. 63 | 1. If they often do not show up in Meetings, Slack, or E-mails. 64 | 1. If they never take ownership of KOSS. 65 | 1. If they repeatatively do not care about how our meetings or events happen in their absense. 66 | 1. If they never take leadership of KOSS. If they never take any initiatives or never took part in any initiative by one of their batchmates. 67 | 1. If they depend upon their batchmates all the time. If they never volunteer and take up any work by their own. 68 | 1. If they clearly feel or state that they do not belong here and are not interested in committing their time to KOSS.. 69 | 70 | Note: One semester may not be enough to judge. Preferably do it after [Governance Review Week](/community/governance-review-week.md). 71 | 72 | ## ~~How do we classify a CTM as Executive Head and Executive Member?~~ 73 | 74 | ~~The answer to this question should come from - the [Governance doc](/community/governance.md).~~ 75 | 76 | ~~After the Governance Review Week, all Executives and Advisors meet and decide for each CTM. Here are some guidelines -~~ 77 | 78 | 1. ~~Read the governance doc thoroughly and judge.~~ 79 | 1. ~~An Executive Head must be self-motivated about KOSS.~~ 80 | 1. ~~An Executive Head must be capable of leading a new batch of KOSS.~~ 81 | 1. ~~Think about all the new Executive Heads as a group. Their should not be any friction in it.~~ 82 | 1. ~~Do not select a scary low number of Heads. Keep it 3-6.~~ 83 | 84 | In a physical meeting in Kgp campus it was mutually decided that the Division of Executives into Executive Members and Heads should be discontinued. Reasons are mentioned in [ISSUE-15](https://github.com/kossiitkgp/docs/issues/15) 85 | -------------------------------------------------------------------------------- /community/one-on-one.md: -------------------------------------------------------------------------------- 1 | +++ 2 | toc=true 3 | +++ 4 | 5 | # 1:1 6 | 7 | > Pronounced as *one on one* 8 | 9 | During Freshers' Induction, every [Core Team Member](/community/governance.md) is assigned one (or more) Executive(s) as 1:1 mentor(s). The mentee and mentor(s) decide the frequency, length, time, venue and nature of their 1:1 meetups. 10 | 11 | A 1:1 can be about 12 | * Career goals of Mentor/Mentee 13 | * Feedback/Discussion about involvement in KOSS 14 | * Brainstorming on new ideas/articles and implementations 15 | * Creating a comfort zone for new members to open up with the team 16 | 17 | ## Notes 18 | * Use Calendar to schedule your 1:1. Use the weekly/bi-weekly/monthly schedule feature. 19 | * Come prepared with questions to ask or points to discuss. You can create an email thread between you and your mentor and log notes after the meetups. 20 | * 1:1 mentorship is voluntary. Every Executive does not need to be a mentor if they are unable to commit their time. 21 | * Mentors can invite any Advisor in any meeting. 1:1s are informal and inclusive. 22 | * Mentors can be changed upon request by either the mentor or the mentee. 23 | * Create a google doc/notion page for listing out resources discussed in the meet. 24 | * If a particular task needs to be accomplished then the mentor can take regular follow ups regarding the task. (Here task refers to any self help goal.) 25 | 26 | ## Guidelines for the mentors 27 | * Make sure your mentee feels comfortable. 28 | * Let the mentee know that 1:1s are about them. 29 | * Do not repeatedly cancel scheduled 1:1s. You may be creating a lot of impact on someone's KGP journey by taking 30 minutes out of your week. 30 | * Some questions to ask your mentee are 31 | * How are you feeling? 32 | * What is on your mind? 33 | * What are you most excited about? 34 | * What are you most worried about? 35 | * Is there anything we should start doing as a team? 36 | * How do you want our 1:1s to go? Do you have any preferences? 37 | 38 | ## Guidelines for the mentees 39 | * The meetups are about you. Be comfortable and use your mentor(s) as resources to discuss anything you wish. 40 | * Some questions to ask your mentor(s) are 41 | * What do you think about my involvement in KOSS? How can I improve upon it? 42 | * Have you ever been in situation X? How did you solve it? 43 | * I am working on X these days. Do you have any suggestions or feedback? 44 | * I am thinking about learning X. Can you tell me the pros/cons of doing so? 45 | * Tell me something about yourself which I might not know. 46 | -------------------------------------------------------------------------------- /community/posters.md: -------------------------------------------------------------------------------- 1 | # Event Poster Guidelines 2 | See also: The [design](https://github.com/kossiitkgp/design/) repository. Please add all poster designs to this repository. 3 | 4 | ### Poster Design Guidelines 5 | #### Size 6 | - For printable posters, the size must be **11.5x17.5 inches** (A3) to be printed properly. 7 | - For social media posters, a portrait orientation is preferred. 8 | - Instagram restricts images in a post to **1:1 ratio** or **4:5 portrait ratio**. A cropped or modified version of the poster may be required to post on Instagram but the print version should be prioritized. [This](https://pinetools.com/blurred-frame-images-generator) tool can be used to add blurred borders to the image. 9 | 10 | #### Content 11 | - The name "Kharagpur Open Source Society" or "KOSS" and a logo must be mentioned in a prominent position. 12 | - Event posters: 13 | - Each poster must include a date, time, and location of the event. 14 | - Contact numbers of at least two people in-charge must be included on the poster. 15 | - Posters that will be stuck on campus must include a QR code linking to a place where more information could be obtained or registration process could be done. The link could be to a website, a document, or a form. 16 | - If the poster is about an event that has a sponsor, the poster must be first approved by the sponsor and must adhere to their brand guidelines. 17 | 18 | ### Poster Printing Guidelines 19 | - Shops at IIT Kharagpur that print posters: 20 | - Quest Printers, Near Radhakanta Sweets, Tech Market. 21 | - The poster must be printed in A3 portrait size. See [#Size](#size). 22 | - The poster must be readable, and the text must not be blurry. A sample should be printed and reviewed by other members before printing the final posters. 23 | - An invoice must be generated in the name of "Kharagpur Open Source Society" for the posters printed. 24 | 25 | ### Poster Pasting Guidelines 26 | - Posters must be pasted on notice boards and other prominent places of every hall and other frequently visited locations such as the Main building, Gymkhana, and famous night canteens. 27 | - Make sure to buy or arrange for push pins, tape, and scissors. 28 | - The following table contains a rough number of posters to be printed per location: 29 | 30 | #### Poster Locations 31 | 32 | > **Note** Following is the minimum count. It is recommended to have 4-5 extra posters more than the total count below. 33 | > This may solve one of the two things: 34 | > - If some new location is discovered, can be pasted there and reflected here as well. 35 | > - If some poster gets damaged they can be used as replacements. 36 | > > It is fine to have 4-5 extra posters but not fine to miss these minimum requirements. 37 | 38 | ##### Total 39 | |Category|Number of Posters| 40 | |-|-| 41 | |Freshers' Halls (as of 2023-2024)|21| 42 | |Other UG Halls|39| 43 | |Non-UG Halls|0| 44 | |Others|9| 45 | |**Total**|68| 46 | 47 | ##### Halls 48 | |Location|Number of Posters|Details| 49 | |-|-|-| 50 | |Azad|5|1 on main notice board + 1 outside mess + 1 in each 2nd year block (3)| 51 | |Patel|4|1 on main notice board + 1 outside mess + 2 in 2nd year blocks| 52 | |Nehru|3|1 on notice board + 1 in each 2nd year block (2)| 53 | |HJB|2|1 on the main notice board + 1 in the mess corridor notice board| 54 | |JCB|2|1 on the main notice board + 1 outside the mess| 55 | |VS|2|1 on entrance noticeboard + 1 on main noticeboard| 56 | |LLR|2|1 on entrance noticeboard + 1 on main noticeboard| 57 | |MS|3|1 on the main noticeboard + 1 on the noticeboard in the rightward passage + 1 outside the mess| 58 | |RK|3|1 on noticeboard + 2 in 2nd year blocks| 59 | |RP|3|1 on noticeboard + 2 in 2nd year blocks| 60 | |LBS|8|~1000 freshers; 1 in front of each mess (2) + 3 in D block + 3 in C block| 61 | |MMM|6|~400 freshers; 1 per mess (2) + 1 per block, besides the elevator (4)| 62 | |MT|4|1 on the main noticeboard + 1 outside Nescafe + 1 outside mess + 1 near D/E block staircase| 63 | |SNVH|3|1 on the main noticeboard + 1 outside the mess + 1 outside the elevator| 64 | |IGH|5|All girl freshers| 65 | |SNIG|3|1 in the reception + 1 in the C-block entrance + 1 near the staircase| 66 | |Gokhale|2|~160 freshers; 1 on the main noticeboard + 1 on the pillar between mess and cycle stand| 67 | |BRH|-|No UG students here _for now_| 68 | 69 | ##### Others 70 | |Location|Number of Posters|Details| 71 | |-|-|-| 72 | |Main Building|2|1 on the main noticeboard, opposite Maggu room + outside raman auditorium| 73 | |Library|1|Noticeboard on the pillar| 74 | |Gymkhana|2|1 on the outer noticeboard + 1 on the inner noticeboard| 75 | |Nalanda|3|1 outside the entrance + 1 near the staircase + 1 outside the backside entrance| 76 | |HJB Night Canteen|1|On shed pillars| 77 | -------------------------------------------------------------------------------- /community/recruitment.md: -------------------------------------------------------------------------------- 1 | +++ 2 | toc=true 3 | +++ 4 | 5 | # Recruitment 6 | 7 | ## Whom do we recruit? 8 | We recruit UG 1st years in the team, preferably after they have spent one semester on the campus. We can also recruit any 2nd year in their third semester, based on recommendations by the members. 9 | 10 | ## How do we recruit? 11 | For more detailed description, refer [Freshers' Selection](/events/freshers-selection.md) 12 | 13 | ## Do we accept M.Tech and Ph.D students? 14 | No. By acceptance, we mean that they will hold a number of responsibilities 15 | - Attend our meetings 16 | - Participate in conducting our workshops and help with the required logistics 17 | - Collaborate on projects together 18 | - Be an active member of the society 19 | 20 | However, we have been collaborating with non-KOSS members since forever. They are welcome to join/lead our events or pitch something to us. If they want to talk about something, we can have them in one of our meetings as well. 21 | -------------------------------------------------------------------------------- /community/socials.md: -------------------------------------------------------------------------------- 1 | # Socials 2 | Guidelines regarding handling, releasing posts, and transferring access to the official KOSS social media accounts. 3 | 4 | ### List of Socials 5 | - [Facebook](https://www.facebook.com/kossiitkgp/) 6 | - [Instagram](https://www.instagram.com/kossiitkgp/) 7 | - [Twitter](https://twitter.com/kossiitkgp) 8 | - [LinkedIn](https://www.linkedin.com/company/kharagpur-open-source-society) 9 | - [Whatsapp Channel](https://whatsapp.com/channel/0029VaR3Adf8vd1TKOUtCo3W) 10 | 11 | ### Post Release Guidelines 12 | - Try to include a poster in every post. **NOTE: Instagram posts cannot be shared without an image.** 13 | - Long links should be shortened using a tool such as https://bit.ly. 14 | - Instagram posts do not allow links. The link should be added to the bio and in a comment instead, and this should be mentioned in the post. 15 | - A short and **to-the-point** post and poster should be shared on Whatsapp groups and statuses. 16 | - Twitter guidelines: 17 | - The number of words in a tweet is limited, so the post may have to be split into paragraphs and posted in a thread. 18 | - The post content must be shortened to include only the most essential information. 19 | - Try to include the most relevant information in the main tweet. 20 | - A poster, if present, must only be added to the main tweet of the thread. 21 | - Whatsapp guidelines: 22 | - The image has to have a 1:1 ratio to be properly displayed in messages without clicking. 23 | - [This](https://pinetools.com/blurred-frame-images-generator) tool may be used to add blurred borders to the image to make it 1:1. 24 | - The Whatsapp channel may be used for sharing posts regarding KOSS events as well as important open-source community news (eg: GSoC announcements) or interesting articles to keep the community engaged. Do not share too many posts as it leads to spam. 25 | 26 | ### Resharing/Reposting Guidelines 27 | - Posts from organizations such as MetaKGP that align with the views of KOSS or relevant posts from other KOSS members can be reshared/reposted from KOSS social media accounts. 28 | - Each reshare suggestion **must** be discussed with other team members on Slack before posting it on any platform. The suggestion must be approved by at least *one executive and one advisor*. 29 | - The repost must link back to the original post. 30 | - Platform wise Guidelines: 31 | - On Facebook: 32 | - "Share to Feed": Share with a caption. 33 | - "Share Now": Share without a caption. 34 | - On Twitter: 35 | - "Quote": Share the original tweet with a caption. 36 | - "Repost": Share without a caption otherwise. 37 | - On LinkedIn: 38 | - "Repost with your thoughts": Share the post with a caption. 39 | - "Repost": Share without a caption. 40 | - On Instagram: 41 | - "Story": Generally, posts should be added to the story. 42 | - "Collaborative Post": In rare cases, a collaborative post can be released if approved internally, and the other organization agrees. (See [Instagram documentation](https://help.instagram.com/5861247717337470/?cms_platform=iphone-app&helpref=platform_switcher)) 43 | 44 | ### Direct Message and Comment Reply Guidelines 45 | - One executive should be assigned to each social media platform to read comments under posts and direct messages at least once a day and reply. 46 | - Simple queries can be replied to directly. 47 | - Suggestions and other questions which may require discussion should be posted on Slack and discussed with executives and advisors. 48 | 49 | ### Transferring Access 50 | #### Facebook 51 | - An existing executive or advisor with access to the Facebook page gives access to the new executives. 52 | - Select the "Full Control" option while giving access. 53 | - More information [here](https://www.facebook.com/help/187316341316631). 54 | 55 | #### LinkedIn 56 | - An existing admin (executive or advisor) adds the new executives as admins. 57 | - Go to the settings > Manage admins > Add admin 58 | - Add each of the executives and select "Super Admin" permissions. 59 | - More information [here](https://www.linkedin.com/help/linkedin/answer/a541981). 60 | 61 | #### Instagram and Twitter 62 | - Instagram and Twitter accounts must be logged into to make a post. 63 | - The credentials to these accounts will already have been shared with the new executives. 64 | 65 | #### Whatsapp Channel 66 | - This is not clear as of now as it is an experimental Whatsapp feature. 67 | 68 | ### Revoking Access (For Offboarding) 69 | #### Facebook and LinkedIn 70 | - An existing executive or advisor with access to the page revokes access from the pages. 71 | - See the [Transferring Access](#transferring-access) section for links to help articles for the same. 72 | 73 | #### Instagram and Twitter 74 | - If the said member had access to these socials, change their passwords and update the [passwords](https://github.com/kossiitkgp/passwords) repository. 75 | - Notify the password change on Slack. 76 | 77 | #### Whatsapp Channel 78 | - This is not clear as of now as it is an experimental Whatsapp feature. 79 | -------------------------------------------------------------------------------- /events/_index.md: -------------------------------------------------------------------------------- 1 | # Events 2 | 3 | Docs for all the events and classes we conduct, both internal and external. 4 | -------------------------------------------------------------------------------- /events/elastic-search.md: -------------------------------------------------------------------------------- 1 | # ElasticSearch, You Know For Search 2 | 3 | ## What was the event about? 4 | 5 | Aravind Putrevu, a developer advocate for Elastic, gave a talk on the rising usage of ElasticSearch and also presented a demo 6 | on how easy it is to setup and run. 7 | 8 | ## Archives 9 | 10 | ### 2019 11 | 12 | Facebook Teaser - https://www.facebook.com/kossiitkgp/posts/2142807422462913 13 | Facebook Announcement - https://www.facebook.com/kossiitkgp/posts/2152998678110454 14 | Facebook Event - https://www.facebook.com/events/2360503774228061/ 15 | Event Slides - https://noti.st/aravindputrevu/3ngeiZ/elasticsearch-you-know-for-search 16 | Facebook Teaser - https://www.facebook.com/kossiitkgp/posts/2142807422462913 17 | 18 | Facebook Announcement - https://www.facebook.com/kossiitkgp/posts/2152998678110454 19 | 20 | Facebook Event - https://www.facebook.com/events/2360503774228061/ 21 | 22 | Event Slides - https://noti.st/aravindputrevu/3ngeiZ/elasticsearch-you-know-for-search 23 | Photos - https://photos.app.goo.gl/MvJCZ6BsuySWqPKG9 24 | -------------------------------------------------------------------------------- /events/freshers-selection.md: -------------------------------------------------------------------------------- 1 | # Freshers' Selection 2 | 3 | ## How do we recruit? 4 | 5 | > This should be carefully re-evaluated every year. People change, along with the needs of KOSS. 6 | 7 | Core parameters for hiring are 8 | 9 | - Knowledge 10 | - Will to Learn 11 | - Will to Teach 12 | 13 | The parameters are given equal weight. 14 | 15 | ### Mailing 16 | 17 | All the mails sent during the selection process are sent using the [mailing-scripts](https://github.com/kossiitkgp/mailing-scripts). It already has all of the templates of the mail which are to be sent during any round. 18 | 19 | > **Warning** You must first test the scripts before sending the mails officially. 20 | 21 | ### Screening Round 22 | 23 | An online form is released with few questionnaires. We carefully go through their answers and invite potential candidates for a sit-in interview with the team. We do this to focus more on the interviews with the eligible candidates. 24 | 25 | Questions on the form for screening round - 26 | 27 | * Name 28 | * Roll Number 29 | * Email ID 30 | * Phone 31 | * Share with us your URLs (GitHub, portfolio, any projects, etc.) 32 | * Do you have any achievements you want us to know? 33 | * When did you start programming? What motivates you? Tell us your story. 34 | * What are you learning these days? 35 | * What other societies/clubs/fests are you a part of or you want to be? How long have you been there? What are your opinions about them? 36 | * Write your skills (Languages, frameworks, design skills, etc.) 37 | * Why do you want to join KOSS? What are your expectations? 38 | * Enlist all of your interactions with the KOSS community over the year 39 | * Any comments? 40 | 41 | ### Interview Round 42 | 43 | We form a few panels consisting of 3-5 people. Each panel should have at least one advisor. The interviewers evaluate them during the conversation. If a candidate does not have any projects done so far, a task must be given to check code quality. The tasks are on spot or to be completed within 24 hours. 44 | 45 | ## Panel Discussion and the release of results 46 | 47 | We all meet a few days after the interview round and discuss each potential candidate. A Physical meeting is required before finalizing the list of new members. 48 | 49 | Also see [Onboarding/Offboarding](/community/onboarding-offboarding.md) 50 | 51 | ## Guidelines 52 | 53 | * Have a physical meeting to discuss the selection of freshers every year. 54 | * Make sure the form reaches all the freshers. Good marketing is recommended. 55 | * Make the students comfortable during the interview. Freshers can get nervous and you may not get to know them completely. 56 | * For on-spot tasks, judge by their effort. 57 | * Give the interviewees an experience to remember. Talk politely and be curious in them. 58 | * It is important that the panelists write detailed comments for every candidate after their interview. This helps in judging them later. 59 | * Do not share the Sheets (responses, interview comments, etc.) with KOSS internet accounts. Maintain them on personal accounts. There is no need to archive them. 60 | * Do not share Sheets with the link (use email addresses to add collaborators). Limit possibility of the new members viewing the sheets in the future. 61 | * Do not discuss selections on public channels on Slack or Google Group. 62 | 63 | ### Red Flags 64 | 65 | **What do we mean by Red Flags?** 66 | 67 | > If you spot a red flag, you say No at the very moment. No second thoughts or arguments. 68 | > The Red flags listed below do not mean they are bad qualities as a programmer or as a human being. They only mean that the person is not a cultural fit for KOSS. 69 | 70 | * Mentions disinterest in Teaching. 71 | * Mentions disinterest in Learning. 72 | * No idea what Open Source is (little knowledge is not a red flag) 73 | * Highly involved in Competitive programming (as a sport) 74 | * “Let us join just another society”-kind of attitude 75 | * "I want to learn coding/data". Thinks KOSS is a society which teaches members to code. 76 | * Mentions “Google Summer of Code” as the primary reason to join KOSS 77 | * Member of a society/club/fest with high involvement (ACell/KTJ/SF/E-Cell) 78 | 79 | ### Positive points 80 | 81 | * Participated in KWoC or Summit 82 | * Follows KOSS, already in touch with any of its members 83 | * Tried tools/frameworks with a mindset to explore 84 | * Passion 85 | * Self-confidence 86 | 87 | ### Negative points 88 | 89 | * Showing off grades in PDS or CG/SG 90 | * Inability to express or communicate clearly 91 | * Trying to flatter by talking against Competitive Programming or praising KOSS too much. 92 | * Thinks lowly / of stuff like FrontEnd Designing or designing in general. 93 | 94 | Note: Negative points differ from Red Flags. A Red Flag is too serious to consider. However, negative points do not indicate rejecting a candidate. The interviewers need to make extra effort in understand the interviewee. They may also require extra attention from the Executives/Advisors to align with our ideologies. 95 | 96 | ## FAQs 97 | 98 | ### Why do we hold selections in the spring semester? 99 | 100 | JEE Students do not do serious programming before coming to KGP. Hence, we give them a semester to explore their interests as well as attend workshops/events in the Autumn semester. 101 | 102 | ## Can we recruit second-year students as well? 103 | 104 | Yes, absolutely! A few of KOSS members joined in their second year. However, it should be done as early as possible (in their Autumn semester). We should not hire second year students in their spring semester because that would create a whole lot of difference in the batch, which soon would become Executives. 105 | 106 | ## What is the ideal number of students to recruit? 107 | 108 | A batch with more than 15 people is hard to manage. Increasing the team size makes it difficult to have like-minded people in the entire team across all the batches. Also, we should not be doing anything which requires the involvement of more than 15 people in every batch. 109 | 110 | ## Archives 111 | 112 | ### 2022 113 | 114 | Facebook post - https://www.facebook.com/kossiitkgp/posts/pfbid02S19YQMn8VfVfxtHRNoS6xZcDe8GbjLZweaeyg1MDfiZAzk1u7iywvu1DZ6zX6AQpl 115 | 116 | ### 2021 117 | 118 | Facebook post - https://www.facebook.com/kossiitkgp/posts/pfbid02nn4ctPmbCDJ4nAXtsik7sXWzsNZXYLPsDpWJYiJpaaBfboeACWCb5GPX1FXM4yxHl 119 | 120 | ### 2020 121 | 122 | Facebook post - https://www.facebook.com/kossiitkgp/posts/4040891799321123 123 | 124 | ### 2019 125 | 126 | Facebook post - https://www.facebook.com/kossiitkgp/posts/2072478999495756 127 | 128 | ### 2018 129 | 130 | The selection still followed direct walk-in interviews. The interviews were conducted on two days. The number of people who showed up was large compared to the number of interviewers. The experience was tiring and very repetitive with people who did not align with our principles. It was then decided that we should not do direct walk-in interviews. 131 | 132 | Facebook post - https://www.facebook.com/kossiitkgp/photos/a.551030724973932/1642194875857506/?type=3&theater 133 | 134 | ### 2017 135 | 136 | Facebook post - https://www.facebook.com/kossiitkgp/photos/a.551030724973932/1230476980362633/?type=3&theater 137 | 138 | ### 2016 139 | 140 | A single round of interviews was conducted. Around 50 people showed up. We used Google Sheets to note down interview comments. 141 | 142 | Facebook post - https://www.facebook.com/kossiitkgp/photos/a.551030724973932/993755030701497/?type=3&theater= 143 | -------------------------------------------------------------------------------- /events/git-and-github.md: -------------------------------------------------------------------------------- 1 | # Git & Github Workshop 2 | 3 | ## Aim of the Workshop 4 | 5 | The workshop should cover and explain the following 6 | 7 | - Why Version Control Systems are needed? 8 | - Usage of basic Git commands to track their projects - Staging and Committing 9 | - Be able to push and pull code from GitHub 10 | - Be able to send a PR to an Open Source Repository 11 | 12 | ## Timeline 13 | The Workshop should be held around the time when Gymkhana societies have their introductory seminar so that we also show our presence during the same time but with a workshop. 14 | Gymkhana societies have their introductory seminars in mid-August, so it's best to conduct the Workshop by the end of August. 15 | ## Before the workshop 16 | 17 | Share an instructions file like [this installation guide](https://github.com/kossiitkgp/events/blob/main/2023/Autumn/Git-github/installation.md), along with the poster of the workshop. The instructions should contain 18 | 19 | - How to install Git for Windows, Linux, and Mac separately 20 | - For Windows users, make that they install `git bash` and configure it 21 | - How to verify that git is installed 22 | - Instructions on how to create a Github Account 23 | 24 | In the post mention the fact that we will be available for installation issues before 15 minutes of the workshop. Help with the installation issues before the workshop begins. 25 | 26 | ## Connecting Github Account 27 | While SSH authentication is a secure and efficient way to interact with GitHub, it may not work on the campus network. 28 | Alternative : 29 | - Use Personal Access Tokens. 30 | - Use Browser Login Method. 31 | 32 | ## Flow of the workshop 33 | 34 | 0. **How will the workshop proceed** 35 | 36 | Explain that Git and GitHub are important parts of Software Development. Tell them how the workshop will proceed like when should audience ask queries. Tell the audience that doing hands-on by themselves along with the workshop will help them learn better. Encourage them to ask questions, as some of the Git concepts are non-intuitive. 37 | 38 | 1. **Terminal Commands** 39 | 40 | It might be a good idea to introduce basic Linux Commands, as they will be used throughout the workshop. You don't have to cover this topic in detail. Just important commands like - `ls`, `cat`, `echo` , `cd`, `mkdir`, `pwd` , `rm` would suffice. Windows users can be asked to try these commands on Git Bash. 41 | 42 | 2. **Why do we need something like Git** 43 | 44 | Before teaching anything, it is important that the audience understand why they are learning it. Start with an example, with which they can connect. Note that most of the audience might not have collaborated on a software. You can give an example of a folder, containing so many files, which are regularly updated. Tell them that tools called "Version Control Systems" are used to track projects. Tell them the importance of maintaining History and backups. Then you can tell that how such tools are useful in Software development and conclude that Git is used to track Software projects. 45 | 46 | 3. **Mental Model of Git**: 47 | 48 | Directly jumping to the terminal would confuse the audience. It might be frustrating for the audience to type commands that they don't understand. Hence, first explain how Git tracks your project. Tell that Git stores snapshots of the project and each snapshot is referred as a commit. You can show a `git log` of a good project, to convey the idea of how snapshots are taken at every feature. 49 | 50 | Explain the idea of staging area very carefully and clearly. Tell them that before storing snapshots, it is important to add them to a staging area. Show them a picture depicting the workflow - 1. git add 2. git commit. 51 | 52 | Note: Though it might be tempting to introduce the concepts of Decentralized VCS and Centralized VCS, Merkle Tree. Please refrain from jumping to complex concepts. We have only 3 hours. It is important that we convey them knowledge of practical usage. One can use Git comfortably without knowing Merkle Trees. But making audience comfortable with Git requires some time and effort. So, it's worth investing time in making the basics strong. However, you can share the links/resources to such concepts at the end of the workshop for the curious audience. 53 | 54 | 4. **A demo** 55 | 56 | A small demo of how a git repository is initialised. Creating files and adding them to staging area. Commit the changes. While you are typing the commands, do explain the audience what these commands do. For example, while typing `git add FILE` , tell them that now this will add `FILE` to the staging area. You can use `git status` after each command to show the status of changes - changes have been staged, changes have been committed. 57 | 58 | Though any demo works, it is a good idea to demonstrate something that's closer to daily life examples. For demo purpose, you can create a project as a "Facebook clone". You don't have to write any real code. You can simply create a text file and something to demonstrate that some X feature has been added, and commit it. The audience will indirectly absorb the idea the commits are made after every feature is added or after every bug is fixed. 59 | 60 | 5. **Stop and Revise** 61 | 62 | It is a good time to stop and revise the concepts. Staging area is a non-intuitive concept. Try using analogies to make the idea clear(For analogies [refer answer by Spoike](https://softwareengineering.stackexchange.com/questions/119782/what-does-stage-mean-in-git)). Ask the audience if they have any doubts. In an offline session, TAs can individually clear people's queries. 63 | 64 | 6. **Reverting using Git** 65 | 66 | This is better done using a demo. Show them the following 67 | 68 | - How to undo changes made after a commit using `git checkout 69 | - How to remove changes from the staging area 70 | - How to go back commits using `git reset --hard` 71 | 72 | (This can be done using a story. For example, an evil cat makes changes in your projects and you use git commands to revert those changes) 73 | 74 | 7. **Branching** 75 | 76 | Branching is another non-intuitive concept. You can start with a problem of how difficult it is to have multiple copies of a project with multiple people working on it. The problem should be posed in such a way that its ultimate solution has to be Git Branching. This will help them better understand why branches are important. You can show the commit trees of different branches and how they diverge. Also, show how the tree merges after git merge. 77 | 78 | Tools that can be used - [https://git-school.github.io/visualizing-git/](https://git-school.github.io/visualizing-git/) 79 | 80 | 8. **Branching demo** 81 | 82 | You can use the "Facebook clone" project for the demo. Make a branch for a new feature. Make some commits in the new branch and show the commits. Jump to the `master` branch and show that the newly made commits are absent(To convey the idea that different branches have different commits). Merge the newly created branch and show how commits have appeared. 83 | 84 | Make sure to speak while you are typing the commands, explaining what the commands do. For example, tell them that you are creating a new branch while typing `git branch BRANCH` and tell them that you are hoping on to the newly created branch while typing `git checkout BRANCH` 85 | 86 | Again it is a good point to stop and summarise branching. Pause for a short period of time. Let the audience ask their queries. 87 | 88 | 9. **Introduce Github** 89 | 90 | Now once the audience is comfortable with the basics of Git. It is the right time to introduce Github. Tell them, how Github is important for software development. Give an analogy of people writing a shared Google doc, and explain collaborative software development better. 91 | 92 | 10. **Push and Pull** 93 | 94 | This is best explained via demo. First, show them how to create SSH keys and how to add the generated keys to Github. Show them how to make a new repository on GitHub. 95 | 96 | Show them how to push the local project to the Github repo using `git push git@github.com:USERNAME/REPONAME.git master`. Make a README on repo on GitHub. Show them how the changes on the Github repo can be obtained locally via `git pull git@github.com:USERNAME/REPONAME.git master`. 97 | 98 | Tell them typing the URL is a pain every time, and use this as an opportunity to introduce the concept of remote variables. Add a remote by name `origin` using `git remote add origin` and show how `git push origin master` does the same job. 99 | 100 | 101 | 11. **Sending a Pull Request** 102 | 103 | This is also best explained via a demo. Use the [sandbox](https://github.com/kossiitkgp/sandbox) repo. Make a small issue like a "typo in `printf` function" which anyone can solve. Follow up the whole process from checking the issues, comment on issue you want to work on, Forking the repo, Cloning it, Making a new branch, Push it, Sending a Pull Request with a proper description. 104 | 105 | While demonstrating each and every step explain clearly, why you are doing this. For example, tell them that you are forking the repo to have your own copy of the codebase. Similarly, make your explanation in such a way that steps have a logical sequence. 106 | 107 | After the demo, show them pictorially all the steps from Forking to Sending a PR. Ask the audience to send a PR. Tell them that sending the PR is the most important takeaway of the workshop. TAs in the workshop can provide individual assistance. If needed, you can show the demo again. 108 | 109 | Finally, merge a PR that contains a well-written description to complete the process. 110 | 111 | 12. **Conclusion** 112 | 113 | - Tell them to contribute to beginner-friendly issues at metakgp or KOSS repositories on GitHub. Share the Github Links of both the Github Organizations. Pointing them to some beginner-friendly issues would be great. 114 | - Tell them about the Github Student pack and its benefits like Domains, Free Servers, and so on. 115 | - Tell them about Github Pages, and tell them how easily a beautiful blog can be set up within minutes. 116 | - Inform them about Hacktoberfest, GsoC & KWoC. 117 | - Tell them about starring a repo and the usefulness of starred repos. 118 | - Tell them about the "watch" feature of a repo, and show them how it can be used to track a project. 119 | - Ask them to `star` and `watch` the [events](https://github.com/kossiitkgp/events) repo, as important links like slides, and resources will be put here 120 | 121 | If any swags are available distribute them to the audience. 122 | 123 | ## After the workshop 124 | 125 | Upload the following in the [events](https://github.com/kossiitkgp/events) repo: 126 | - Recording of the workshop, if it's recorded 127 | - Link to the slides 128 | - Link to extra resources, from which they can revise or learn more advanced stuff. Something like [this](https://github.com/kossiitkgp/events/tree/main/2023/Autumn/Git-github/resources) 129 | 130 | Share the above via a Facebook post along with a thanks to the audience. 131 | 132 | ## PLEASE DO NOT 133 | 134 | - Introduce an idea or feature directly without explaining why it is needed. Just starting with "Branching is an important feature and to create a new branch, we use `git branch` command" is a bad way to introduce branching. Make sure you firmly establish in the audience's mind why they are learning. If you can't explain why in the beginning make a promise that it will be explained later and keep your promise. Otherwise, our workshops will be no different than most of the boring academic lectures. 135 | - Skip hands-on sessions. Hands-on sessions are the main reason we conduct workshops, else the audience would have simply watched a tutorial video. Repeat demos if required. Provide individual assistance. Make sure the audience gets their hands dirty. 136 | - Skip questions. Git contains many non-intuitive ideas. The audience may be confused while you are explaining the concepts. Re-explain things in a different way if necessary. Encourage the audience to speak out if they are confused. Tell them that Git is non-intuitive and it's okay to ask small doubts. 137 | 138 | ## KOSS Intro 139 | Include 4-5 slides introducing KOSS, focusing on: 140 | - when we do selections. 141 | - why we do it at that time. 142 | - what we expect from them. 143 | - what they need to do/learn to get selected. 144 | 145 | This introduction can be inserted in the middle of the workshop when the maximum audience is present. 146 | 147 | ## Miscellaneous 148 | - We can also consider conducting an Advanced Git workshop, where concepts like `rebase`, `stash`, and `bisect` are taught. The duration of this workshop can be shorter than the duration of a regular workshop(3 hours). If such a thing is being planned, make sure to give some git exercises in the gap between git basic workshop and git advanced workshop, so that they are in touch with git concepts. 149 | - `switch` is the new preferred way to switch branches. This might be included in the upcoming workshops. Refer [this](https://www.banterly.net/2021/07/31/new-in-git-switch-and-restore/). 150 | 151 | ## Feedback Form 152 | Include an _anonymous_ form at the end of the slides and ask the audience to share their experience and suggestions. 153 | Some questions to include in the feedback form can be (Including all the questions below is not necessary): 154 | - How well can you now explain Git-Github to someone totally new in this field? (1-5) 155 | - Can you revert a commit with errors now? (Yes / No) 156 | - I don't want the changes made by you recently, which are not yet committed. Can you quickly roll them back? (Yes / No) 157 | - How well did you grasp the concept of Git branching? (1-5) 158 | - Are you confident enough to push that important file into the GitHub repository? Or try pulling the doc? (Yes / No) 159 | - How well did you understand the flow of making a Pull Request? (1-5) 160 | - How helpful were the workshop materials, such as slides and handouts, in your learning process? (1-5) 161 | - Do you feel more confident in collaborating with others on GitHub after attending this workshop? (Yes / No) 162 | - Were there any specific topics or concepts related to Git and GitHub that you expected to be covered in the workshop but were not? (descriptive) 163 | - Did you encounter any challenges or areas of confusion during the workshop? If so, please describe them. (descriptive) 164 | - How did you find the pace of the workshop? (too slow, perfect, too fast) 165 | - How likely are you to apply the knowledge and skills gained from this workshop in your future projects or work? (1-5) 166 | - What more could we have done to improve your learning experience? (descriptive) 167 | - How relevant and useful did you find the workshop? (1-5) 168 | - Any other suggestions? (descriptive) 169 | 170 | ## Useful Resources 171 | - [Git-School](https://git-school.github.io/visualizing-git/): Visualizating git.This can be used while the workshop 172 | - [Git Parable](https://tom.preston-werner.com/2009/05/19/the-git-parable.html): Understanding Git concepts from ground up. It will be useful if speakers of the workshop go through this once. This can also be shared with the audience 173 | - [Git Immersion](https://gitimmersion.com/index.html): A guided tour walks through the fundamentals of Git. This can be shared with the audience. 174 | - [Git-The Simple Guide](https://rogerdudler.github.io/git-guide/): A handy cheat sheet. This can be shared with the audience. 175 | -------------------------------------------------------------------------------- /events/kossprint.md: -------------------------------------------------------------------------------- 1 | # KOSSprint 2 | KOSS internal code sprint. 3 | 4 | ## What is KOSSprint? 5 | - It's an internal event held to efficiently collaborate on large projects or accelerate slowed-down work, where KOSS members sit together for 2-3 hours and work on KOSS projects, slides, documentation, etc. 6 | - It boosts productivity and encourages discussion and collaboration among KOSS members. 7 | 8 | ## When to conduct a KOSSprint? 9 | - Sprints can be done whenever a lot of coding work (or any other work) is pending. 10 | eg: 11 | - For planning a workshop, all can work together to make slides and poster. 12 | - During KWoC, all can work together to update the frontend, backend, mailing, etc. 13 | - Suggested days: 14 | - Weekends 15 | - Suggested times: 16 | - 10pm - 1am 17 | 18 | ## Where can KOSSprint be conducted? 19 | - The place should have a good internet connection, enough plug points, and no time restrictions (as sprints are usually held around midnight). 20 | - Some suggested venues: 21 | - Maggu Room 22 | - Lbrary -------------------------------------------------------------------------------- /events/kwoc.md: -------------------------------------------------------------------------------- 1 | ## First things first 2 | 3 | - KWoC is a month-long event, generally conducted in December. 4 | - Registrations start at least a week before the coding period (more than a week is preferred). 5 | - Coding period is generally 4 weeks long 6 | - Mid evals are held around 2 weeks after start of the coding period. 7 | - End evals are done after the coding period 8 | 9 | ## Pre-registration 10 | 11 | - The following things should be ready (or updated) :- 12 | 13 | - KWoC Website: 14 | - Registration feature, should be tested internally. 15 | - Last year's stats. 16 | - Last year's testimonials. 17 | - FAQs. 18 | - Student and Mentor Docs of KWoC. Make sure that the content of the doc is updated with the current rules of KWoC(especially rules like Mid Evals and End Evals criteria). If there are any new important changes, do mention them in the docs. 19 | 20 | - A dedicated slack workspace for KWoC. If the old one has reached the maximum free limit, create a new Slack workspace. 21 | 22 | - Printing and circulation of posters to every hall's, main building's and nalanda's notice boards. 23 | 24 | - Intro Seminar of KWoC should be conducted, a week before the registrations begin. 25 | 26 | - If possible approach a few organisations or companies - well before the website goes live - to sponsor KWoC for providing swags/goodies to the top-contributors (the number of top-contributors might vary based on what we get in the swag). Do NOT term them as `winners` - [KWoC is not a competition](https://github.com/kossiitkgp/mistakes/blob/kwoc-22-mistakes/kwoc20.md#5-reduce-competive-nature-) 27 | 28 | 29 | 30 | ## Registration: 31 | 32 | - It is recommended to start the registrations in the first week of November. At maximum, the registrations should begin by third week of November. Please do not delay the registrations further. 33 | - It is suggested that Student, Mentor and Project Registrations begin at the same time. 34 | - Release a Facebook, Twitter and LinkedIn Post from KOSS account. The post should contain the following things: 35 | - Briefly about KWoC 36 | - Mentor and Student Docs' Links 37 | - Instructions to register 38 | - A KWoC workspace invite link. (Already existing one or New Slack workspace can be created) 39 | - Mail previous year's students and mentors that kwoc is back - along with working registration links. 40 | - Make sure to take database backups periodically. 41 | - When projects are being registered, they should not be immediately shown on the Projects Page. The projects should be shown only when they are accepted. During the registration period, the projects should be accepted frequently(atleast on a daily basis). The guidelines to accept projects are discussed [here](https://github.com/kossiitkgp/mistakes/blob/master/kwoc20.md) (2nd point in `Logistical` section). If we are rejecting a project, mail the mentor why we are doing so. 42 | 43 | ## Complaints and Queries 44 | 45 | It is suggested a group of dedicated people from KOSS handle complaints and queries through out KWoC. The responsibilities can be split shift wise - One group can handle complaints during the day and the other during the night. However, **please make sure that the queries are answered within 24 hours**. KOSS members should be active at the following places to answer queries and complaints 46 | 47 | - Facebook, Instagram, Twitter, and Linkedin of KOSS account. 48 | 49 | - KWoC Slack workspace 50 | 51 | - Mails received at admin@kossiitkgp.org 52 | 53 | - A Github Repo for Technical complaints. For example refer [this](https://github.com/kossiitkgp/kwoc-bugs) 54 | 55 | - Discord Server of KWoC. 56 | 57 | Make sure to keep the FAQ page exhaustive and detailed. Update the FAQ page from regularly if new frequent queries come up. Along with answering the queries, it is a good idea to share the FAQ Page of KWoC, so that future queries can be addressed without need of contact. 58 | 59 | ## Coding Period 60 | 61 | - Sometimes due to serious reasons, participants(students or mentors) miss out the registration period. In such cases, collect the details from the participant and add their entry in the database manually. 62 | - Make sure that the site is regularly up and working, especially the stats tables. A group of people should be vigilant in this matter. 63 | - Any important changes or announcements(like informing in case of spam, changing Mid evals dates) are to be made on both website and via email. 64 | - If a project is not approved then mail the mentor immediately for "Why their project is not healthy for KWoC" and "What they can do for it to be approved" (if possible). 65 | 66 | ## Mid Evals 67 | 68 | - It is important to inform about the Mid evals and its criteria via email and KWoC website atleast 3 days before the Mid evaluation. 69 | - **Mid evals criteria**: 70 | - **KWoC 20 criteria**: Having atleast one commit before was the criteria for clearing Mid evals. If the mentor has been inactive and the PR remains unmerged. We asked the students to mail 71 | - In the previous KWoCs, there was a form, which was to filled by mentors. However, to automate stuff the single commit criteria was implemented. 72 | - You are encouraged to make changes in the Mid Eval criteria, but make sure that it is fair and is not too hard to clear. (Remember, KWoC is meant to encourage beginners) 73 | - In case of serious emergencies, do not hesitate cancel mid evaluations. For example, in 2019 when there was a ban of internet in few states, the mid evals were cancelled. 74 | - In case, if any individual is unable to clear mid evals due to some genuine reasons, it should be considered. 75 | - Mail the students a day or two before the dead-line of mid-evals as a last reminder. 76 | - Announce the results of Mid-Evals via mailing the students (in both cases) & via a pop-up on student's dashboard. 77 | 78 | ## End evals 79 | 80 | - **End evals criteria**: 81 | - Till KWoC 20, the end evals criteria was asking the students to write a blog that summarizes their work. And the students would be evaluated based on the blog. 82 | - The above criteria was made to make sure that no mentor would unfairly pass/fail a student as per his/her wish. 83 | - Feel free to come up with any other criteria for End evals, but make sure that no student should have an unfair advantage. 84 | - If blog criteria is being followed 85 | - Make sure to inform the students atleast a week time after the coding period ends to write the blog 86 | - Inform the criteria for end evals via email. Examples of previous blogs should be given. 87 | - If a student was unable to submit his/her blog before the deadline due to some genuine reasons. Do consider it later, its a month long effort! 88 | - **Evaluation of blogs**: 89 | - For evaluation, distribute the blogs among members of KOSS for evaluation 90 | - While evaluating, if a member finds some blog that doesn't seem to clear the end evals, make sure to cross verify the same with other members of KOSS 91 | - It is good to inform the participants by what date, they might expect the results of KWoC after they have submitted their End evals Blog. 92 | 93 | # Feedback 94 | Share an **anonymus** feedback form with following 95 | 1. Some objective questions, where they can rate about different aspects of KWoC-website, doubts clarification,coding experience. 96 | 2. Subjective questions - What did they like about KWoC, What did they didn't like about KWoC, Anything they would like to tell us. 97 | 98 | ## Certificates 99 | 100 | - Along with the name of the participant, the certificate must contain the following links 101 | - Verification link: A link of certificate hosted on a Public repository of KOSS - [kossiitkgp/public-files](https://github.com/kossiitkgp/public-files) 102 | - Stats link: A link containing the Student's or the Project's stats respectively for a student or a Mentor. 103 | 104 | - Move the website from `kwoc.kossiitkgp.org` to `kwoc{Y}.kossiitkgp.org` (e.g. `kwoc19.kossiitkgp.org` for KWoC19). Thereafter, the stats are hosted on the latter while the former is reused next year. 105 | 106 | - The certificates must be hosted on the public files repo - [kossiitkgp/public-files](https://github.com/kossiitkgp/public-files) 107 | - The certificates in PDF formats should be sent via mail to the participants. 108 | 109 | ## Miscellaneous 110 | 111 | - Take anonymous feedback about the proceedings of KWoC from participants. Preferably after the submission of the end evals blog. 112 | 113 | - Update [kossiitkgp/mistakes](https://github.com/kossiitkgp/mistakes) repo for the sake of posterity based on feedback and other things that went wrong. 114 | -------------------------------------------------------------------------------- /events/lightning-talks.md: -------------------------------------------------------------------------------- 1 | # Lightning Talks (LT) 2 | 3 | ## What are Lightning Talks? 4 | - An event where CTMs present about a topic chosen by them, be it tech-related or not. 5 | - Each presentation should be of around 15 min. 6 | 7 | ## Purpose of the Event 8 | - To motivate CTMs to enhance their speaking and presentation skills (as they would be the ones conducting upcoming workshops). 9 | - To encourage healthy discussion among CTMs. 10 | 11 | ## Before the Event 12 | - The event can last for 4-6 hours, so time can be divided into 2 days accordingly. 13 | - Schedule the slots between CTMs in advance. 14 | - Room (with AV support) must be booked for the event. 15 | 16 | ## After the Event 17 | - Update the [slides](https://github.com/kossiitkgp/slides/tree/main/Lightning-Talks) repo. 18 | - If the event is recorded, the recording(s) may be uploaded on YouTube after discussion and approval on Slack. 19 | - If uploaded, add links for the same in the `slides` repo. 20 | -------------------------------------------------------------------------------- /events/room-booking.md: -------------------------------------------------------------------------------- 1 | # Room Booking 2 | Steps for room and AV (Audio Visual) cell booking for conducting workshops and other events. 3 | 4 | ## Steps for Room Booking 5 | >**NOTE**: that room booking must be done **7 days** prior to the day of the event and the booking procedure takes at least **4-5 days**. 6 | - Room has to be booked from a professor's ERP (Academic -> Facility Booking -> Central Classroom Booking), using his employee ID. No physical forms are required. [Guide](./../assets/Online%20Room%20booking.pdf) 7 | - Request the professor to book the room, giving them the necessary details: venue, dates and time. 8 | - Room availability can only be checked at the same portal, so it's preferable if someone from KOSS asks to meet the professor offline for the procedure. 9 | - When the room is allocated, the professor will be mailed (maybe) and there will be a memo available next to the request at the portal (sure). 10 | - This memo must be printed and shown to the guard with the keys. In the worst case, the email and pdf memo can be shown. 11 | - Support for mic and projector is booked separately at the [AV Cell](#steps-for-booking-av-audio-visual-cell). 12 | 13 | ### Room Booking During CDC 14 | - During CDC internships and placements (August - December), all Nalanda classrooms and Vikramshila rooms are booked by the CDC. 15 | - In order to conduct a workshop during this period, explicit written permission is required from the CDC to use a room in the above-mentioned venues. Payment for the room booking is not required. 16 | - This permission can only be obtained with the approval of a professor. 17 | - If a professor agrees to approve the booking, they will have to send an email to CDC (`tnp-off@hijli.iitkgp.ac.in`) with us (`admin@kossiitkgp.org`) and `tnp-placecom@hijli.iitkgp.ac.in` in cc, asking for permission to conduct the event on our behalf. [This](#email-template-for-asking-permission) template can be used to send the draft email to the professor. 18 | - Best case, the permission will be emailed back and should be kept and shown to the guard on the day of the event. If only CDC's approval is emailed back, to get the permission, follow the same steps as mentioned [above](#steps-for-room-booking) for room booking. Along with the form, attach the screenshot of the email from CDC. 19 | - The [AV Cell booking](#steps-for-booking-av-audio-visual-cell) booking should be done separately through the normal procedure. Payment is required for AV cell. The permission email might be asked for during the AV cell booking process. 20 | 21 | #### Email Template for Asking Permission 22 | > **NOTE**: Replace placeholders for the professor's name, our contact number/email ID, venue, room number, event name, date, and time. 23 | ``` 24 | Respected Prof. [Name], 25 | 26 | Here is the mail draft we request you to send to [tnp-off@hijli.iitkgp.ac.in](mailto:tnp-off@iitkgp.ac.in) and cc to [tnp-placecom@hijli.iitkgp.ac.in](mailto:tnp-placecom@iitkgp.ac.in) along with this e-mail id. If there is anything to be conveyed to us, you may contact us at [contact number or email id]. 27 | 28 | ---------------- 29 | Kharagpur Open Source Society (KOSS) would require one of the bigger [Nalanda/Vikramshila] Classrooms, preferably [Room Number]. 30 | 31 | Details of the event are as follows: 32 | - Name : [Event Name] 33 | - Date : [Date] 34 | - Time : [Time] 35 | 36 | As the rooms are currently booked by CDC, I request you, on behalf of KOSS, to provide one of the preferred classrooms for the above-mentioned date and time. 37 | ---------------- 38 | ``` 39 | 40 | ## Steps for booking AV (Audio Visual) Cell 41 | - Get the AV cell "Requisition Form" from the AV cell control room in Nalanda (ground floor) or from the CWISS (Central Workshop & Instruments Service Section) office opposite the Mining Department. 42 | - The form may also be scanned and printed. [Here](../assets/av-cell-requisition-form.pdf) is a scan of the form. 43 | - Fill in the required details and get it signed by a professor. 44 | - Preferably, the student filling out the form should be in the same department as the professor signing the form. 45 | - For `User Name with Cell No`, fill in the name of the *student* filling the form and their phone number. 46 | - For `User designation with EC No. / Roll No`, fill in just the roll number of the student. 47 | - For `Users' Deptt./Centre/Society`, fill in "Kharagpur Open Source Society." 48 | - For `Equipments Required`, mention mic and speaker for audio and projector for screen sharing. 49 | - The professor's seal must be stamped on the signed form from the respective department's office. 50 | - Submit the form to the control room in Nalanda if the booking is for any room in Nalanda Complex; otherwise, submit it to the CWISS Office. 51 | 52 | ## Points to be noted 53 | - Keep at least **2 weeks** in hand before booking a room, the process takes time. The booking must be done at least **7 days** prior to the day of the workshop and the procedure can take 4-5 days, excluding weekends. 54 | - AV Cell booking can be done 2-3 days in advance but it is still better to do it at the earliest along with room booking. 55 | - UPI payment is accepted while paying at the cash counter (Establishment Section, 2nd Floor, Above Raman Auditorium, Main Building). 56 | - Both the form for room booking and AV cell need the professor's signature; better to get it done together. 57 | - Contact the AV Cell staff and AC maintainers of Nalanda one day before the event to notify them. [Here](../assets/av-cell-contacts.jpg) is a list of contacts. 58 | 59 | ## Rates of Room w.e.f Oct 5, 2022 60 | | Sl no. | Name of the Auditorium | Seating Capacity | 4hrs | 8 hrs | 61 | | ------ | ---------------------------------------- | ---------------- | ---- | ----- | 62 | | 1 | Bhatnagar (F-116) / Raman (F-142) | 300 | 2000 | 3000 | 63 | | 2 | S-301/S-302 | - | 1500 | 2500 | 64 | | 3 | V1/V2 Class Room | 359 | 2000 | 3000 | 65 | | 4 | V3/V4 Class Room | 179 | 1500 | 2500 | 66 | | 5 | Nalanda Class Room (Upto 4 rooms with AC)| 4\*120 or 240 | 5000 | 8000 | 67 | | 6 | Nalanda Class Room (Per room without AC) | 120 | 500 | 800 | 68 | --------------------------------------------------------------------------------