Latest revision as of 16:03, 15 February 2023

This page is not actively maintained.

Before working on any of the internship ideas on this page, contact the listed Mentor to find out whether the idea is still relevant.

You can also take a look at the current Outreachy proposals, which are up-to-date: https://www.outreachy.org/apply/project-selection/#openstack

Finally, you can take a look at the current "Upstream Investment Opportunities", which lists projects of interest to the community that don't have owners: https://governance.openstack.org/tc/reference/upstream-investment-opportunities/

To submit new ideas please consider creating a new page and use the Template:InternshipIdea (instructions are provided on that page) and you can see how a sample idea page would look like. The pages created with such template are listed on Category:Internship_idea.

List of Ideas for Internships

The OpenStack Foundation has multiple sources for internships, from Outreachy to Google Summer of Code and other opportunities. This page collects the ideas for candidate interns to work on.

Applicants may not have ever worked on FLOSS before and have different levels of competence. Since we have different programs, add here ideas that can be completed by inexperienced contributors, developers or other fields (marketing, communication, graphic design, and anything that may be useful for OpenStack and to include new people in this community).

Coding

OpenStack as a virtual Kubernetes node

Implement a virtual Kubernetes node that allows running containers/pods on OpenStack. Students applying to work on this will learn about Zun and Kubernetes, and will work on implemeting a whole new feature for Zun, which will include not only coding but also testing and documentation efforts. See https://github.com/virtual-kubelet/virtual-kubelet/issues/22 for more info on the requirement

Difficulty	Medium
Topics	OpenStack Zun, Kubernetes
Required skills	Python Go
Extra skills
Mentor	hongbin on IRC channel #openstack-zun @ freenode
Status	Looking for candidates.
Program

Improve Cinder integration for Docker containers

Add support for Cinder volume multi-attach for Docker containers. Students willing to take this task will learn about Zun and Cinder. During the Ocata cycle a new flow for volume attaching has been implemented in Cinder. We want to make Zun leverage this new flow. Implementing this will require the student not only contribute with code, but also with testing and documentation for the feature. Check https://blueprints.launchpad.net/zun/+spec/cinder-volume-multi-attach for more details.

Difficulty	Medium
Topics	OpenStack Zun, OpenStack Cinder, Docker
Required skills	Python
Extra skills
Mentor	hongbin on IRC channel #openstack-zun @ freenode
Status	Looking for candidates.
Program

Help Implement Support for a Generic Backup Driver in Cinder

The goal is to create a generic backup driver that be used to turn any Cinder volume backend into a target for backups. This way, we won't need to implement specific backup driver for supported backends. Students picking this internship task will learn about Cinder and will be asked to contribute with testing and documentation of this feature. Refer to https://review.openstack.org/#/c/504099/1/specs/queens/generic-backup-implementation.rst for more detials

Difficulty	Medium
Topics	OpenStack Cinder, Storage
Required skills	Python
Extra skills
Mentor	jungleboyj and e0ne on IRC channel #openstack-cinder @ freenode
Status	Looking for candidates.
Program

Eliminate Redundant Downloads of Uncached Images

An important component in the amount of time it takes to boot a new virtual machine is how long it takes to get the image being used from backend storage down to the host. To speed this up, Glance has optional caching middleware that for some back ends (specifically, OpenStack Swift), significantly improves performance. The problem is that the cache is kind of stupid, and in the scenario where someone wants to boot 1000 VMs from the same image, each request will discover that the image isn't cached, and will initiate a download from the storage backend, resulting in severely degraded performance.

There are some complexities to improving the caching middleware that are discussed in a Glance specification document: http://specs.openstack.org/openstack/glance-specs/specs/untargeted/glance/duplicate-downloads.html . In addition to coding, you will get exposure to working in an open-source community from the design phase through implementation, because your first task will be to re-propose the spec to the Glance community so that it can be reviewed and re-approved. (Don't worry, this won't drag on because it was already approved once; it is untargeted because the original developer was reassigned to a different project.) This is an interesting project that will touch several Glance components: the API server, the caching middleware, and the glance_store library. And, of course, you'll be adding good tests.

Difficulty	Low to Medium (you don't need previous OpenStack experience, but you need to be self-motivated enough to learn the components of Glance and how they interact)
Topics	Glance
Required skills	Python
Extra skills	General distributed systems knowledge
Mentor	jokke_ on IRC channel #openstack-glance @ freenode
Status	Looking for candidates.
Program

Transform legacy notifications to the new versioned framework in Nova

Help transforming legacy Nova notifications to a new versioned framework. Students applying for this task will learn about Nova and the oslo.messaging library, and will help transforming the legacy notifications of Nova to a proper versioned API using an already established framework. Check for more details on this page https://wiki.openstack.org/wiki/Nova/VersionedNotificationTransformation

Difficulty	Medium
Topics	OpenStack Nova
Required skills	Python
Extra skills
Mentor	gibi on IRC channel #openstack-nova @ freenode
Status	Looking for candidates.
Program

Policy Testing

WIth all the system-scope work coming down the pipe and landing in Queens, we need to be prepared to rethink out test_v3_protection.py test module. This is the module responsible for making it so policies are doing what they should. Since we're adding a few new combinations with system scope, this should result in a test explosion that could be difficult to maintain and understand.

Can we come up with a way to flexibly test different policy cases
Refactor current coverage
Integration with Patrole

Difficulty	Medium
Topics	OpenStack Keystone
Required skills	Python
Extra skills
Mentor	hrybacki and lbragstad on IRC channel #openstack-keystone @ freenode
Status	Looking for candidates.
Program

Flask support

We have a home-grown WSGI implementation when there are suitable frameworks to do that lifting for us. We can get rid of a wheel to maintain by moving to a framework and ditching the home-grown implementation. We've talked about moving to Flask for a while. The benefits would be less maintenance of a home-grown implementation.

Difficulty	Medium
Topics	OpenStack Keystone
Required skills	Python
Extra skills
Mentor	TBA
Status	Looking for candidates.
Program

Native SAML

Currently, federation requires the use of Apache plugins to do the SAML processing. We want to experiment with a piece of middleware that can go into keystone paste pipeline to process SAML according to specification. This will make federation easier to configure for deployers and it has the ability to reduce a mapping currently used in federation (assertions -> env var, env vars -> keystone mappings).

Difficulty	Medium
Topics	OpenStack Keystone
Required skills	Python
Extra skills
Mentor	cmurphy and rodrigods on IRC channel #openstack-keystone @ freenode
Status	Looking for candidates.
Program

Make keystone a fully-fledged IdP

Currently, keystone can act as an IdP but only in a non-standard in-house-designed auth flow, not with WebSSO. We could implement the rest of the WebSSO standard in keystone. https://bugs.launchpad.net/keystone/+bug/1470205 This could be a good warm-up bug for either this or the Native SAML project: https://bugs.launchpad.net/keystone/+bug/1641625

Difficulty	Medium
Topics	OpenStack Keystone
Required skills	Python
Extra skills
Mentor	TBA
Status	Looking for candidates.
Program

OpenStack Manila Integration with OpenStack CLI (OSC)

OpenStackClient (aka OSC) is a command-line client for OpenStack that brings the command set for Compute, Identity, Image, Object Store and Volume APIs together in a single shell with a uniform command structure. OSC primary goal is to provide a unified shell command structure and a common language to describe operations in OpenStack. Manila basic commands should be added to OSC client. This will be helpful for user to provide a unified shell command structure to describe operations in OpenStack.

Difficulty	Low
Topics	OpenStack Manila
Required skills	Ruby
Extra skills	Python
Mentor	enriquetaso and vkmc on IRC channel #openstack-manila @ freenode
Status	Looking for candidates.
Program	Outreachy May-Aug 2019 candidates.

@@ Line 1: / Line 1: @@
 <!-- ## page was renamed from [[GnomeOutreachWomen]]/Ideas -->
+<div style="font-size: 150%; background-color: yellow; padding: 1em">
+<span style="font-size: 150%">This page is not actively maintained.</span>
+<br/><br/>
+Before working on any of the internship ideas on this page, contact the listed Mentor to find out whether the idea is still relevant.
+<br/><br/>
+You can also take a look at the current Outreachy proposals, which are up-to-date:
+https://www.outreachy.org/apply/project-selection/#openstack
+<br/><br/>
+Finally, you can take a look at the current "Upstream Investment Opportunities", which lists projects of interest to the community that don't have owners:
+https://governance.openstack.org/tc/reference/upstream-investment-opportunities/
+</div>
 To submit new ideas please consider creating a new page and use the [[Template:InternshipIdea]] (instructions are provided on that page) and you can see how a [[Test idea|sample idea page]] would look like. The pages created with such template are listed on [[:Category:Internship_idea]].
 =  List of Ideas for Internships =
@@ Line 12: / Line 25: @@
   {{InternshipIdea|
-  TITLE=Murano - Murano package validation tool |
+  TITLE=OpenStack as a virtual Kubernetes node|
-  DESCRIPTION=Murano cloud-ready applications are written in MuranoPL language and are packaged into zip packages, with certain prerequisites obligatory (manifest file, package structure, etc.). Having a murano package verification tool would speed up development and debugging of such apps greatly. Package verification tool should include tools for verifying that package structure is correct, all the class files mentioned in manifest file are present. It should also include MuranoPL linting code, to speed up MuranoPL-app development. Finally after the tool is ready — we should implement checks at import level (when importing a package to murano-api) and jobs at commit-time for murano-apps |
+  DESCRIPTION=Implement a virtual Kubernetes node that allows running containers/pods on OpenStack. Students applying to work on this will learn about Zun and Kubernetes, and will work on implemeting a whole new feature for Zun, which will include not only coding but also testing and documentation efforts. See https://github.com/virtual-kubelet/virtual-kubelet/issues/22 for more info on the requirement|
-  DIFFICULTY=Medium |
+  DIFFICULTY=Medium|
-  TOPICS=Murano |
+  TOPICS=OpenStack Zun, Kubernetes|
-  SKILLS=Python |
+  SKILLS=Python Go|
-  EXTRA_SKILLS=YAML |
+  EXTRA_SKILLS=|
-  MENTORS=kzaitsev |
+  MENTORS=hongbin on IRC channel #openstack-zun @ freenode |
-  STATUS=Not Started |
+  STATUS=Looking for candidates.|
-  PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
+  PROGRAM=
 }}
 {{InternshipIdea|
-TITLE=Neutron - Metering agent add port statistics |
+ TITLE=Improve Cinder integration for Docker containers|
-DESCRIPTION=Neutron the metering agent collects statistics regarding bandwidth usage. Right now it only measure the bandwidth used by routers. The idea is to extend it and provide statistics also for ports. In the first implementation only openvswitch will be supported, since we will use openvswitch tools to get the port statistics. The first step will be getting familiar with the metering agent and with Neutron in general. Then you will approach openvswitch tools and think about how to use them for this project. After that you can reach out to the community to collect and discuss ideas. Neutron folks are pretty active on #openstack-neutron channel most of the time and would be willing to share their opinions on this or any other project. You'll submit your code upstream and address the comments you get till your patch gets merged.  |
+ DESCRIPTION=Add support for Cinder volume multi-attach for Docker containers. Students willing to take this task will learn about Zun and Cinder. During the Ocata cycle a new flow for volume attaching has been implemented in Cinder. We want to make Zun leverage this new flow. Implementing this will require the student not only contribute with code, but also with testing and documentation for the feature. Check https://blueprints.launchpad.net/zun/+spec/cinder-volume-multi-attach for more details.|
-DIFFICULTY=Medium-Advanced |
+ DIFFICULTY=Medium|
-TOPICS=Neutron |
+ TOPICS=OpenStack Zun, OpenStack Cinder, Docker|
-SKILLS=Python |
+ SKILLS=Python|
-EXTRA_SKILLS=Networking, OVS |
+ EXTRA_SKILLS=|
-MENTORS=rossella_s |
+ MENTORS=hongbin on IRC channel #openstack-zun @ freenode |
-STATUS=None |
+ STATUS=Looking for candidates.|
-PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
+ PROGRAM=
 }}
 {{InternshipIdea|
-TITLE=Neutron - ovsdb client monitor for Windows |
+ TITLE=Help Implement Support for a Generic Backup Driver in Cinder|
-DESCRIPTION=The OVS agent monitors the ports that are added in the compute host to be able to wire them correctly. In Linux it uses the class InterfacePollingMinimizer that notifies the agent when a new port is plugged or unplugged and passes the related events (port added or deleted). For Windows it uses the class AlwaysPoll that doesn't notify any specific event, it returns always true. The OVS agent in Windows is forced to rescan the devices currently in the machine to infer which were added. This is because the current Windows implementation of the interface polling manager doesn't use ovsdb client monitor. The aim of this project is to use ovsdb client monitor also for Windows and make sure that the events are passed correctly to the OVS agent. This will improve the performance and will enable some clean up in the OVS agent code. The first step is getting familiar with the OVS agent and with Neutron in general. Then you will approach openvswitch tools and investigate how to use ovsdb monitor client in Windows. Neutron folks are pretty active on #openstack-neutron channel most of the time and would be willing to share their opinions on this or any other project. You'll submit your code upstream and address the comments you get till your patch gets merged.  |
+ DESCRIPTION=The goal is to create a generic backup driver that be used to turn any Cinder volume backend into a target for backups.
-DIFFICULTY=Medium |
+This way, we won't need to implement specific backup driver for supported backends. Students picking this internship task will learn about Cinder and will be asked to contribute with testing and documentation of this feature. Refer to https://review.openstack.org/#/c/504099/1/specs/queens/generic-backup-implementation.rst for more detials |
-TOPICS=Neutron |
+ DIFFICULTY=Medium|
-SKILLS=Python |
+ TOPICS=OpenStack Cinder, Storage|
-EXTRA_SKILLS=Networking, OVS |
+ SKILLS=Python|
-MENTORS=rossella_s |
+ EXTRA_SKILLS=|
-STATUS=None |
+ MENTORS=jungleboyj and e0ne on IRC channel #openstack-cinder @ freenode |
-PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
+ STATUS=Looking for candidates.|
+ PROGRAM=
 }}
-{{InternshipIdea|
+ {{InternshipIdea|
-TITLE=Glance - Extended support for requests library |
+ TITLE=Eliminate Redundant Downloads of Uncached Images|
-DESCRIPTION= You would be learning about glance-replicator, glance_store drivers and if time permits other modules. You are then expected to add support for requests library ( https://pypi.python.org/pypi/requests ) starting with glance-replicator. Although, supporting more than glance-replicator is not expected, more support you add the better your internship will be. You will also help with bug triage and optimizations around that code base as you add more support. |
+ DESCRIPTION=An important component in the amount of time it takes to boot a new virtual machine is how long it takes to get the image being used from backend storage down to the host.  To speed this up, Glance has optional caching middleware that for some back ends (specifically, OpenStack Swift), significantly improves performance.  The problem is that the cache is kind of stupid, and in the scenario where someone wants to boot 1000 VMs from the same image, each request will discover that the image isn't cached, and will initiate a download from the storage backend, resulting in severely degraded performance.
-DIFFICULTY=Medium |
-TOPICS=Glance |
+There are some complexities to improving the caching middleware that are discussed in a Glance specification document: http://specs.openstack.org/openstack/glance-specs/specs/untargeted/glance/duplicate-downloads.html .  In addition to coding, you will get exposure to working in an open-source community from the design phase through implementation, because your first task will be to re-propose the spec to the Glance community so that it can be reviewed and re-approved. (Don't worry, this won't drag on because it was already approved once; it is untargeted because the original developer was reassigned to a different project.)  This is an interesting project that will touch several Glance components: the API server, the caching middleware, and the glance_store library.  And, of course, you'll be adding good tests.|
-SKILLS=Python |
+ DIFFICULTY=Low to Medium (you don't need previous OpenStack experience, but you need to be self-motivated enough to learn the components of Glance and how they interact)|
-EXTRA_SKILLS=Good communication skills |
+ TOPICS=Glance|
-MENTORS=nikhil |
+ SKILLS=Python|
-STATUS=Open |
+ EXTRA_SKILLS=General distributed systems knowledge|
-PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
+ MENTORS=jokke_ on IRC channel #openstack-glance @ freenode |
+ STATUS=Looking for candidates.|
+ PROGRAM=
 }}
 {{InternshipIdea|
-TITLE=Glance - Develop a python based GLARE (GLance Artifacts REpository) client library and shell API |
+ TITLE=Transform legacy notifications to the new versioned framework in Nova|
-DESCRIPTION= You will learn how python based clients are developed in the Openstack realm. You will be responsible for closely working with the Glare drivers to understand the requirements, API evolution and contribute ideas to the development of the Glare API. You should be able to set up the basic build structure, common interfaces, setup configs and infra jobs for the glareclient. Co-ordinate with the Glare drivers and infra team to setup repositories, documentation and test jobs for releases of this client. Also, based on the outcome and feedback from the Glare API discussions you will be responsible for keep evolving the client library. |
+ DESCRIPTION=Help transforming legacy Nova notifications to a new versioned framework. Students applying for this task will learn about Nova and the oslo.messaging library, and will help transforming the legacy notifications of Nova to a proper versioned API using an already established framework. Check for more details on this page https://wiki.openstack.org/wiki/Nova/VersionedNotificationTransformation|
-DIFFICULTY=Medium-Advanced |
+ DIFFICULTY=Medium|
-TOPICS=Glance |
+ TOPICS=OpenStack Nova|
-SKILLS=Python |
+ SKILLS=Python |
-EXTRA_SKILLS=Shell scripting & packaging, good communication skills |
+ EXTRA_SKILLS=|
-MENTORS=nikhil |
+ MENTORS=gibi on IRC channel #openstack-nova @ freenode |
-STATUS=Open |
+ STATUS=Looking for candidates.|
-PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
+ PROGRAM=
 }}
 {{InternshipIdea|
-TITLE=Searchlight - Extend automated functional testing for Searchlight plugins  / Improve existing plugins |
+ TITLE=Policy Testing|
-DESCRIPTION= Searchlight is intended to dramatically improving the search capabilities and performance of various OpenStack cloud services by indexing their data into ElasticSearch using plugins. You will be learning the Searchlight fundamentals including indexing, searching, faceting, security, etc. You will also learn the APIs and data models of various other OpenStack services that are indexed into Searchlight. You will understand plugin design then explore all of the functional testing aspects mentioned above. You will be responsible for implementing complete coverage of functional testing for one big or two medium sized plugins. You will improve the existing plugins for any bugs or improvements you discover.  |
+ DESCRIPTION=WIth all the system-scope work coming down the pipe and landing in Queens, we need to be prepared to rethink out test_v3_protection.py test module. This is the module responsible for making it so policies are doing what they should. Since we're adding a few new combinations with system scope, this should result in a test explosion that could be difficult to maintain and understand.
-DIFFICULTY=Medium |
-TOPICS=Searchlight |
+*Can we come up with a way to flexibly test different policy cases
-SKILLS=Python |
+*Refactor current coverage
-EXTRA_SKILLS=Basic understanding of ElasticSearch, good communication skills |
+*Integration with Patrole|
-MENTORS=nikhil |
+ DIFFICULTY=Medium|
-STATUS=Open |
+ TOPICS=OpenStack Keystone|
-PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
+ SKILLS=Python |
+ EXTRA_SKILLS=|
+ MENTORS=hrybacki and lbragstad on IRC channel #openstack-keystone @ freenode |
+ STATUS=Looking for candidates.|
+ PROGRAM=
 }}
 {{InternshipIdea|
-TITLE=OSprofiler - Implement new storage drivers for OSprofiler / add OSprofiler support to other OpenStack projects |
+ TITLE=Flask support|
-DESCRIPTION= OSprofiler is an Oslo library allowing to trace cross-project requests and identify the OpenStack performance bottlenecks via understanding what time was spent on each request stage, how many requests were used, etc. Lots of developing efforts might be found here, including writing new storage drivers for OSprofiler and adding its integration to other OpenStack projects. |
+ DESCRIPTION=
-DIFFICULTY=Medium |
+We have a home-grown WSGI implementation when there are suitable frameworks to do that lifting for us. We can get rid of a wheel to maintain by moving to a framework and ditching the home-grown implementation. We've talked about moving to Flask for a while. The benefits would be less maintenance of a home-grown implementation.|
-TOPICS=OSprofiler |
+ DIFFICULTY=Medium|
-SKILLS=Python|
+ TOPICS=OpenStack Keystone|
-MENTORS=DinaBelova |
+ SKILLS=Python |
-STATUS=Open |
+ EXTRA_SKILLS=|
-PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
+ MENTORS=TBA |
+ STATUS=Looking for candidates.|
+ PROGRAM=
 }}
 {{InternshipIdea|
-TITLE=Magnum - Container Service for Magnum's Kubernetes Orchestration Engine |
+ TITLE=Native SAML|
-DESCRIPTION= Magnum's client has several actions (create/delete/exec/logs/pause/reboot/start/stop/unpause) for containers, currently these commands work only for Docker Swarm COE. When a operator deploys a bay with either Kubernetes COE or the Mesos COE, these command line functionality is not available for the operator as there is not backend support for these operations. In this project, we will first add a concrete implementation for the Container Service that calls Kubernetes API appropriately, then we make sure that the magnum's client command lines work properly against this, just like this works when the operator deploys a bay using swarm COE. |
+ DESCRIPTION=Currently, federation requires the use of Apache plugins to do the SAML processing. We want to experiment with a piece of middleware that can go into keystone paste pipeline to process SAML according to specification. This will make federation easier to configure for deployers and it has the ability to reduce a mapping currently used in federation (assertions -> env var, env vars -> keystone mappings).|
-DIFFICULTY=Medium |
+ DIFFICULTY=Medium|
-TOPICS=Magnum |
+ TOPICS=OpenStack Keystone|
-SKILLS=Python|
+ SKILLS=Python |
-MENTORS=Dims |
+ EXTRA_SKILLS=|
-STATUS=Open |
+ MENTORS=cmurphy and rodrigods on IRC channel #openstack-keystone @ freenode |
-PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
+ STATUS=Looking for candidates.|
+ PROGRAM=
 }}
-== Documentation ==
 {{InternshipIdea|
-TITLE=Performance-docs - Add missing sections to http://docs.openstack.org/developer/performance-docs/# and identify the documentation gaps |
+ TITLE=Make keystone a fully-fledged IdP|
-DESCRIPTION= Performance-docs is quite new initiative leaded and pushed by OpenStack Performance Working Group - https://wiki.openstack.org/wiki/Performance_Team - and we really need your help to work on adding test results, topologies and environments description, etc. to make this source valuable for all community. |
+ DESCRIPTION=Currently, keystone can act as an IdP but only in a non-standard in-house-designed auth flow, not with WebSSO. We could implement the rest of the WebSSO standard in keystone.
-DIFFICULTY=Medium |
+https://bugs.launchpad.net/keystone/+bug/1470205
-TOPICS=Performance-docs |
+This could be a good warm-up bug for either this or the Native SAML project: https://bugs.launchpad.net/keystone/+bug/1641625|
-SKILLS=Good English and great communication skills to collect the information|
+ DIFFICULTY=Medium|
-MENTORS=DinaBelova |
+ TOPICS=OpenStack Keystone|
-STATUS=Open |
+ SKILLS=Python |
-PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
+ EXTRA_SKILLS=|
+ MENTORS=TBA |
+ STATUS=Looking for candidates.|
+ PROGRAM=
 }}
-[[Past internship ideas]]
+ {{InternshipIdea|
+ TITLE=OpenStack Manila Integration with OpenStack CLI (OSC)|
-[[Category: Internship]]
+ DESCRIPTION=OpenStackClient (aka OSC) is a command-line client for OpenStack that brings the command set for Compute, Identity, Image, Object Store and Volume APIs together in a single shell with a uniform command structure. OSC primary goal is to provide a unified shell command structure and a common language to describe operations in OpenStack. Manila basic commands should be added to OSC client. This will be helpful for user to provide a unified shell command structure to describe operations in OpenStack. |
+ DIFFICULTY=Low|
+ TOPICS=OpenStack Manila|
+ SKILLS=Ruby|
+ EXTRA_SKILLS=Python|
+ MENTORS=enriquetaso and vkmc on IRC channel #openstack-manila @ freenode|
+ STATUS=Looking for candidates.|
+ PROGRAM=Outreachy May-Aug 2019 candidates.
+}}

Difference between revisions of "Internship ideas"

Latest revision as of 16:03, 15 February 2023

List of Ideas for Internships

Coding