Capstone projectsMiddleLesson 3357 min read

Share it and get feedback

A short demo, a clear README with honest limits, and a suitable licence turn your project into something others can learn from, and something you can show.

✦ Ask the tutor🧪 Lab · 25 min📝 Lesson test
Lesson in motion

In 60 seconds

Share it and get feedback

A short demo, a clear README with honest limits, and a suitable licence turn your project into something others can learn from, and something you can show.

1/4
In simple words
When you finish a science fair model, you put a card next to it: what it does, how it works, and what it cannot do yet. People who read the card understand your work in one minute, and some of them give you great ideas. Sharing your project is making that card.
A project that only lives on your laptop helps nobody else. Sharing it well means three things: a short demo that shows it working, a README that explains it honestly, and clear permissions for others to use it. Then you ask for feedback and improve.

A two-minute demo

  1. 1

    The problem

    One sentence: who has it and why it matters. Show a real example.
  2. 2

    The tool in action

    Show one real task from your pilot, start to finish.
  3. 3

    An honest failure

    Show one question it gets wrong or says "not found" to, and explain why.
  4. 4

    The result

    Your success measure and what you learned from the pilot, with real counts.
  5. 5

    What next

    One or two things you would improve.
Showing a failure on purpose builds trust. It tells people you tested honestly and know where the edges are.

What goes in the README

SectionWhat to write
What it doesOne or two sentences, in plain words.
Who it is forThe users from your plan, and the language or languages it supports.
How to runSteps to install and run it. Say where the model call goes and that keys must be kept private.
LimitsWhat it cannot do, known mistakes, and when people should ask a person instead.
Data and privacyWhere the content came from, that you had permission, and what it does or does not store.
ResultsYour test set and pilot numbers, with counts and how you measured.
LicenceWhich licence the code uses, and who owns the content.

Licences in general terms

If you share code publicly without a licence, others may not have clear permission to use it. A licence tells people what they may do. Some general families:
  • Permissive licences (for example MIT or Apache 2.0) let others use, change and share your code, including in their own products, as long as they keep the notice.
  • Copyleft licences (for example the GNU GPL) let others use and change your code, but if they distribute their changed version, they must share it under the same licence.
  • Content licences such as Creative Commons are often used for text, images and datasets rather than code.
Note
Your code licence does not cover content you do not own. A school's notices or a shop's price list belong to them: ask before publishing them, or publish only made-up sample content. Models and datasets you use have their own licences and terms, which you must follow. This is general information, not legal advice; for anything important, ask your institution or a qualified person.

Getting useful feedback

  • Ask specific questions: "Was the answer about fees clear?" works better than "Do you like it?".
  • Share with your pilot users first, then classmates, then a wider group.
  • Keep a simple list of feedback, and mark what you fixed, what you will fix later, and what you decided not to do.
  • Thank people. Credit teammates, testers (without personal details) and any content owners in the README.

Your portfolio and your certificate

A finished capstone with a README, a short demo and honest results is strong evidence of what you can do. It is often more convincing than a list of courses. Keep a short write-up: the problem, what you built, what you measured, and what you learned.
On OmniLingo, when you complete every lesson in a track, you get that track's certificate automatically. Each certificate has a link that anyone can use to check it is real. Share the certificate link together with your project link, so people can see both what you learned and what you built.
Watch out
Before publishing, check: no API keys or passwords in the code, no personal data in examples or logs, no content you are not allowed to share, and no claims you cannot back up. Search your files for words like "key", "token" and "password" before you push.
Try this. Ask someone who has never seen your project to read only your README for two minutes. Then ask them what it does and what it cannot do. If they cannot say, improve the README.

Watch and read more

Choose an open source licensechoosealicense.com · readingLicenses approved by the Open Source Initiativeopensource.org · reading

Lab

A README for your project with all the key sections, including honest limits and a licence.

~25 min

The problem

  1. Run the starter. It splits README into sections and shows which ones are still TODO.
  2. Write your own README for your capstone (or for the library bot from this track). Keep the six headings: What it does, Who it is for, How to run, Limits, Data and privacy, Licence.
  3. Write at least ten words under each heading. Under Limits, give at least two bullet points starting with - .
  4. Under Licence, name the licence you chose, or write that you have not chosen one yet and why.
  5. Make sure no keys, passwords or personal details appear anywhere.

Practice lab

Edit the code and run it. Python runs in your browser — nothing is sent to our server.

Output

No output. Add print(...) to see values.

You are done when

Hard questions

Try to answer before you reveal. If you can answer these, you understood the lesson.

Q1Your README says "Our bot answers all library questions accurately." A tester found it wrong twice. How should you rewrite it?Reveal

Replace the claim with what you measured: "In our test set of 20 questions, it answered 17 correctly with the right source and said not found for 2 of 3 questions it had no content for. It can still be wrong; check the source link or ask at the desk." Specific, measured claims build trust; absolute claims break it the first time the tool fails.

Q2You used a school's notices to build the bot, and you want to open-source it. What exactly do you publish?Reveal

Publish your code under the licence you chose, and publish the notices only if the school gives permission. Otherwise, include a small set of made-up sample content with the same format, and explain in the README how someone can add their own content. Also check the terms of any model or dataset you used, and remove any keys or logs with personal data.

Please sign in to continue.

Questions people ask

Do I have to open-source my project?

No. You can keep it private or share only a demo. Open-sourcing helps others learn and shows your work, but only publish what you are allowed to share, and remove private content first.

Which licence should I choose?

Many student projects use a common permissive licence so others can learn from and reuse the code. If you want changed versions to stay open, a copyleft licence may suit you. Read a plain-language guide, check your institution's rules, and ask your mentor. When in doubt about anything important, ask a qualified person.

What if my results are not good?

Share them anyway, honestly. "Our bot answered 6 of 10 questions correctly; here is why it missed the rest" is a useful result. People who read your work value honesty and clear learning more than perfect numbers.

How do I show a group project in my own portfolio?

Name the whole team, and say clearly which parts you did. Link to the shared repository or demo. Being precise about your own role is honest and more convincing.

Lesson test

5 questions. Get 3 right (60%) to pass and complete this lesson.

Sign in to take the test and save your progress