IndiaFOSS Proposal Reviewer Guide
*This was adapted from last year’s policy, this topic is purposefully left without the year in hopse we don’t have to copy/paste every year and just update the policy8
Your Role
As a reviewer, you will assess proposals and collaborate with speakers to refine their talks into acceptable submissions or provide valuable feedback if rejected. Missing the guidelines initially is not sole grounds for rejection; if the talk is quality, reach out to help them adjust.
Submission Quality & Guidelines Checklist
1. Main Track Requirements
- Main track proposals should possess broad relevance and appeal to a large cross-section of the FOSS community. If a topic is highly specialized or niche, look to route it to a devroom.
- The speaker must demonstrate clear expertise, experience, or solid credentials regarding the topic they are proposing.
- Prioritize highly technical, world-class talks. Do not look to water down the core conference tracks for the lowest common denominator.
2. Content & Formatting
- Ensure descriptions are informative but crisp.
- Overly long, AI-written proposals are not immediate grounds for rejection. Ask the submitter to trim it and re-write the core details in their own words. (Assistance for grammar or spelling is fine).
- Language should adhere to inclusive standards (Linux Foundation Guide | inclusivenaming.org).
3. Verification & References
- Verify that the software being discussed or promoted is genuinely FOSS (evaluate the license and originality).
- Check the session reference links in the proposal, speakers should be directly linking to the referred project or any other relevant information. Ask the speaker to provide them if missing.
4. Duration Fit
- Evaluate if the topic realistically fits the requested slot. Suggest shifting to a Lightning Talk (10-15 min) or a Full Talk (20-25 min) where appropriate.
Track & DevRoom Routing
If a proposal does not fit the Main track, evaluate if it is a better candidate for one of the specialized tracks or devrooms:
- Cloud & DevOps
- Security
- Open Hardware
- Compilers, Programming Languages, and Systems (including the dedicated Devroom)
- Documentation & Technical Writing
- Open Design
- Real Time Operating Systems (RTOS)
- Android Open Source Project (AOSP)
Feedback Guidelines
Because of the high volume of submissions, we cannot provide extensive back-and-forth for every proposal, but we aim for at least 1 thorough comment per submission after the first round of reviews.
- Frame your guidance around the FOSS United mission: promoting & strengthening the FOSS ecosystem in India, promoting the spirit of hacking/tinkering, building quality FOSS for public good, and evangelizing FOSS in different sectors.
- Reference the FOSS United Talk Proposal Guidelines heavily in your review notes to give clear actionable feedback.