Project Title: Fix bugs and implement some features/improvements

Description: the idea of this project is to implement a set of features and improvements, and help the team to fix bugs that might appear during the GSoC period. The set of features/improvements are as follow:

• Splitting the user_permission/manage_namespace option (see #1109).
• Show Docker image labels (see #1055).
• Improve how we create teams as an admin (see #1024).
• Improve how hidden teams are handled (see #840).
• Allow administrators to reset passwords for users (see #824).
• Audit logs should be immutable (see #899)

Deliverable: the issues mentioned above have been resolved. Moreover, the student has helped the team to fix bugs that have appeared during the GSoC period.

Mentor: Rafael Fernández López @ereslibre / [email protected]
Co-Mentor: Miquel Sabaté Solà @mssola / [email protected]

Skills: Ruby on Rails

Skill Level: Medium

Get started: Take a look at our issues on Github. Try to fix some (note that there are some junior jobs).

Project Title: MirrorPinky - A web frontend for mirror administrators

Description: You might know MirrorBrain already: our download redirector and Torrent/Metalink generator used u.a. on download.opensuse.org. It's really a great tool that plays a hidden key role inside the openSUSE infrastructure and is meanwhile used by many others ( KDE, VLC, DocumentFoundation, ArchLinux - just to name a few).

But while the amount of openSUSE mirrors is increasing over the time (currently we have >180 mirrors in our database!), the amount of main administrators for the database itself is not increasing as well.

It happens, that mirrors want to limit the traffic for a specific time (means for us: decreasing the score of this specific mirror) or changing their setup (means for us: adapting the URLs for FTP, HTTP, rsync or the operator Name and Url - or even the Name and Email of the mirror admin). Not thinking about the work for adding new mirrors or removing old ones. Sometimes it might also be enough to disable a mirror for a short time - and re-enable it after the maintenance work is done. All this is currently done manually on request via mail to [email protected] or [email protected]

But as most of the stuff above only affects single mirrors that are already maintained by people who should know what they are doing, why not allowing them to do the requested steps on their own?

Maybe they can even trigger a "rescan" of their mirror once it is added - or something has changed/fixed?

Deliverable:

• Enhance the current code status on https://github.com/openSUSE/mirrorpinky - finish the outstanding bits and pieces to get the code production ready
• provide tests that cover nearly all current features
• help with packaging and releasing the stuff to the outside world

Mentor:

• Lars Vogdt [email protected] / @lrupp
• Marcus Rueckert [email protected] / @darix

Skills:

• Ruby (required)
• Rails (required)
• CSS/HTML5 (strongly recommended)
• MirrorBrain (strongly recommended)
• PostgreSQL (recommended)
• Python/Perl/RPM packaging (recommended)

Skill Level: medium

Get started:
General everything should be collected/done using https://github.com/openSUSE/mirrorpinky

• setup your local instance of MirrorPinky (see README.development.md)
• start working on the things listed in the TODO section on the Github repo (or add more ;-)

Project Title: Reproducible openSUSE builds

Description: The Reproducible Builds Project is working on making builds of binary packages from sources reproducible so that builds from the same sources always create the bit-wise identical results. This way users can prove that packages are built from the sources they claim to be built from without having to trust the build servers. This can be important to prevent malicious modifications of the binaries during build or to make build processes more efficient by eliminating rebuilds due to changes in builds from unchanged sources.

openSUSE has a lot of technology in this area with the build service, all the packaging infrastructure and tools such as build-compare. The goal of this project would be to make the reproducibility of builds in openSUSE visible, create metrics and tests, and fix issues to make more builds reproducible.

Deliverable: This project is a bit open in what results are expected. A minimal result would be to have tests to measure and track reproducibility of builds, a maximum result would be to have all tests green and be able to build a whole distribution such as Leap in a reproducible way. Other possible results could be a dashboard for reproducible builds in openSUSE, integration with the upstream reproducible build project, or improvements in the tools for building and comparing packages.

Mentor: The project was entered by @cornelius. Mentors are still wanted.

Skills: Building and packaging of software, RPM, familiarity with openSUSE, debugging of build problems, for visualization of tests some web development skills, scripting and shell

Skill Level: Medium to Hard

Get started: Have a look at https://reproducible-builds.org and play around with the concepts and tools there, apply them to openSUSE. We'll define more concrete starting points when the project becomes more concrete.

References

• https://lists.opensuse.org/opensuse-packaging/2015-12/msg00049.html

Description: Jangouts is a really nice videoconferencing tool but it lacks of a good User Interface. Developers have been busy adding new features but, to be honest, the interface didn't get too much love. So the objective of this project is to design and implement a new user interface to improve the UX and make Jangouts great. During the last GSoC, Jangouts was ported to Angular 2, so a mobile friendly Material Design based interface looks like a reasonable approach. However, we're open to other proposals.

Deliverable: A new brand user interface for Jangouts based on Angular 2

Mentor: @imobachgs / [email protected] and @ancorgs / [email protected]

Skills: JavaScript.

Skill Level: Medium

Getting started: Pick something from the list of junior jobs of Jangouts and try to do something about it. For this particular project, you should also check out the angular-2 branch (although we're still working in this branch to get it working at 100%).

Github: https://github.com/jangouts/jangouts/

Project Title: REST API for testing applications based on libYUI

Description: The goal of this project is to add optional REST API for controlling the applications based on libYUI. It should be generic enough to allow various usage like integration testing, remote controlling or reproduction of applications failures.

For more info about the project and the initial proof of concept (POC) code see:

• https://hackweek.suse.com/16/projects/controlling-and-testing-the-yast-ui-remotely-for-integration-tests-openqa
• https://blog.ladslezak.cz/2017/12/06/hackweek-16-yast-ui-rest-api/

Expected communication channels are emails, IRC and daily video calls.

Deliverable:

• OpenSUSE installation is possible with REST commands exclusivelly
• libyui with webserver is a separate package that can be installed on top of libyui (or if not possible as an alternative to libyui without it)
• recording of actions is possible in REST specification.

Mentor: @jreidinger, @lslezak (you can contact both of us on irc://freenode#yast (best during the GMT+1 working hours) or [email protected] (anytime))

Skills:

• REST API
• C++
• Qt or ncurses
• Any scripting language for quick POC and demonstration of usage (see the cucumber integration example)

Skill Level: Medium

Get started:

• Get in touch with mentors
• Try POC from links in description (ideally make the cucumber example also working for you)
• Enhance the POC, implement selecting a RadioButton widget via REST API

The idea is for this repository to hold the web site (gh-pgaes) and to manage mentoring projects in this repos issues. How?

Project Title: Improve the UI of Portus

Description: In this project we encourage students to try to improve the UI of Portus. Some known issues from Portus' UI are:

• Don't allow users access to the hidden team.
• Assets should be served differently. For example, it doesn't make much sense to serve the font "Pacifico" for every page, when it's only used in error pages.
• Create a help section: a simple link to our documentation could be a start, but we would like to hear more ideas.
• Improve the search feature so it also searches for teams and namespaces.
• The repositories container in the dashboard page is a bit cumbersome when there are lots of repos:
  • Allow a search filter.
  • Only show a fixed amount of rows, where the last row is "Show x more repositories", where x is the amount of repositories that are not being shown.
  • Sort by last pushed or last updated
• Allow the filtering of namespaces, teams and team members in the different pages of Portus.
• There should be an "Explore" feature where even non-logged in users could get a list of interesting public namespaces/repositories.

Besides the known issues, we greatly encourage students to try to come up with other improvements in this regard.

Deliverable: most of the tasks mentioned before should be merged into the master branch.

Mentor: Miquel Sabaté Solà @mssola / [email protected]

Co-Mentor: Flavio Castelli @flavio / [email protected]

Skills: CoffeeScript, CSS, Ruby on Rails

Skill Level: Medium

Get started: Take a look at our issues on Github. Try to fix some (note that there are some junior jobs, UI issues, UX issues).

We could just name it mentoring program but maybe that's too boring?

Description: The Machinery project has been evolving in a good pace for the last couple of years by adding features and fixing bugs in an agile way. However there are places where our code base could benefit from:

• a better design
• more readability
• better performance

We will achieve these goals through refactoring so we don't alter the external behavior of the code in the process of getting the benefits in our internal structure.

Deliverable: At the end of this project the student will be able to:

• identify some code smells
• apply a well known refactoring method
• ensure that no regressions were introduced

Mentor: @mauromorales

Skills: Ruby, RSpec, TDD, git

Skill Level: Medium - Hard

Get started: The best way to get started is to:

• Get familiar with Machinery, use it, have a look at the code and some examples.
• Tackle one of our newcomer friendly issues
• Read the refactoring book by Martin Fowler (there is a Ruby edition)

What FOSS projects do we run that have the people/structure to do mentoring?

Goals

• Collect mentoring projects and present them to students/sponsors
• Provide mentoring for mentors (materials, hints, tips & tricks. see #3)
• Present an overview of our Free Software development projects

Description: With Machinery you can inspect Linux systems and store the collected data as a description of the system. The description can be nicely displayed and managed by Machinery. This is useful to get insight into unknown systems, debug problems, track changes, create inventories, migrate systems, and more.

Currently Machinery collects data about RPMs and additionally about files which are not managed by RPM. These unmanaged files are collected as a plain list without looking into further structure.

This project is about doing deeper inspection there and for example track files which are installed directly with Ruby's gem command while bypassing RPM, identify to which gems they belong, and extract the list of installed gems in addition to the installed RPMs.

The same approach could be extended to other package managers such as npm, pip, etc.

Deliverable: A plugin for Machinery which retrieves information about installed gems from a system and stores it in the Machinery data store. Bonus points for covering additional package managers.

Mentor: @cornelius, @aduffeck

Skills: Ruby, RSpec, TDD

Skill Level: Medium

Get started: Get familiar with the tool, use it, have a look at the code

Hosted version of OSEM

Description: The Open Source Event Manager (OSEM) is an event management app tailored to Free Software Conferences, developed in Ruby on Rails. Right now, it is a self-hosted solution, meaning that every conference that wants to use OSEM must have their own servers to host OSEM, as well as install the application and its dependencies. This has some drawbacks: it requires a high technical knowledge (specifically with Rails), and it makes the conference responsible for the up-time and security of the servers. Conference organizer are already quite busy with organizing the conference, and managing servers is not something they want to spend their energy on.
In this project, we want to create a hosted version of OSEM. This means that once installed on a server, any conference organizer in the world will be able to use that installation to create and manage their conference. Sign up, enter your conference details, and off you go.

Some of the work and features involved in this project can include:

• Creating a new level in the permissions hierarchy, "site admins". They would be able to configure site-wide settings. Current conference admins should only be able to manage their own conferences, and not others'.
• Moving some settings that are currently application-wide into conferences (for example, Stripe payment tokens).
• Incorporating revenue-generating features for the hosted OSEM site administrator, for example by earning a percentage of each ticket sold.
• Creating a nice landing page that explains what users can do there, as well as showing upcoming conferences.
• Adding the ability for conferences to use their own domain, while in reality they load from the hosted OSEM's servers.

Deliverable: All the necessary changes in the OSEM code to be able to achieve the project proposal. A demo hosted version of OSEM should be running on a publicly accessible server (eg. Heroku).

Mentor: Hernán Schmidt

• GitHub: @lagartoflojo
• IRC: hernansp on freenode#osem
• Email: hernan [dot] schmidt [at] gmail [dot] com

Skills: Ruby on Rails.

Skill Level: Medium

Getting started: Start with submitting a PR of a junior job. Once you've done that, submit your project proposal as early as possible so that we can polish it before the submission deadline.

IMPORTANT: Students will only be considered if they have successfully worked on at least one junior job, as well as interacted with the OSEM community through GitHub and/or IRC (#osem channel on freenode).

Project Title: Improve one-click installer

Description: The one-click installer would benefit greatly from improved features. Some of these are:

• Port the application to use Qt5 instead of Qt4.
• Localization.
• Handling conflicts and dependency in the backend.
• Better progress interface so the user can see if the application is downloading or installing the package.
• Show which repository each package is coming from.
• etc.

Some mockups of how the application might look can be seen here.

Deliverable: A version of the one-click installer with much improved user interface which is easier to use, gives more information and looks nicer than the current version.

Mentor: @antlarr / [email protected]

Skills: Some knowledge of C++ needed. It would be nice if the student knows the Qt libraries, but it should be possible to learn them while working on the project. Some XML knowledge would be nice too, as the project involves some XML parsing (which is already implemented but might need some changes).

Skill Level: Medium

Get started: To learn about Qt:

• Qt Examples and Tutorials
• Qt Documentation

To port one-click installer to Qt5:

• Qt4.x to Qt5 Porting guide

Start working on one-click installer:

• one-click installer repository

Collect howtos, tips, tricks, books, talks etc. about mentoring.

Description: The YaST module used to configure the keyboard layout needs a revamp. The current source code is poorly structured. Since the original implementation was highly tight to the underlying tools, the adaptation to systemd was hard and is still very far from perfection. Moreover, the final users tend to confuse the system-wide keyboard settings managed by YaST with the user-specific ones managed by the desktop (KDE/Gnome) configuration tools. That's partially YaST's fault, the user experience could be improved to make the difference more obvious.

The goal of this project is to rewrite the keyboard management from scratch in a proper object oriented way. For example, the interaction with systemd should be just one of many possible backends, so the module is ready for the next big change in Linux keyboard management or to be ported to systems without systemd.

Deliverable: A new version of the YaST keyboard layout module that can be distributed as part of openSUSE Tumbleweed. The module must conform to the YaST development guidelines, which means, among other things, that it must include unit tests (RSpec).

Mentor: @ancorgs / [email protected]

Skills: Ruby, Rspec, Object oriented design

Skill Level: Medium

Getting started: Read the new YaST tutorial and write question or suggestions on how to improve it to [email protected] mailing list.

Github: https://github.com/yast/

Description: Jangouts is a videoconferencing solution that can be used to hold meetings with any number of participants. But currently there is no way to record those meetings in order to watch them again. That's a feature that will make Jangouts suitable for many more use cases, like online workshops. This Issue at GitHub describes some possible approaches to implement such feature.

Deliverable: A mechanism to record and play Jangouts sessions, either integrated in Jangouts itself either as an external tool that can connect to a session and produce a video out of it.

Mentors: @ancorgs / [email protected] and @Imobach / [email protected]

Skills: JavaScript

Skill Level: medium

Getting started: Pick something from the list of pending features and bugs of Jangouts and try to do something about it.

Github: https://github.com/jangouts/jangouts/

Project Title: Conference Info Screen for the Open Source Event Manager (OSEM)

Description: From the data available in OSEM build a page that conference organizers can show on screens throughout the venue containing information like the the next talks title&speaker, tweets about the conference, sponsors etc.

Deliverable: A new page in the OSEM ruby on rails app.

Mentors: @ChrisBr @hennevogel @differentreality

Skills: Ruby, Ruby on Rails, HTML, Java Script

Skill Level: Easy

Getting started: Pick one of the Junior labeled issues and get in touch with the mentors.

Github: https://github.com/openSUSE/osem

Project Title: Dockerize Open Source Event Manager

Description: To be able to deploy OSEM even faster to give it a try locally with 0 effort we would like to dockerize app with sattelite containers via docker-compose

Deliverable: executable script + related documentation which will spin up required containers and seed data to get started

Mentor: Artem Chernikov @kalabiyau / [email protected]

Skills: Rails, Ruby, Linux, Docker as a plus

Skill Level: Medium

Get started: Take your time and pick something from OSEM Junior Issues

Description: Jangouts, a web based videoconferencing tool, is based on AngularJS 1.4. Given that the new version of AngularJS (v2) will be fundamentally different from v1.4, Jangouts should be ported to the new version of AngularJS or to an alternative framework (like the combination of React+Redux). On the other hand, Jangouts was born as a HackWeek project and doesn't have a proper testsuite. So during the transition to the new framework a testsuite should be also developed

Deliverable: A new version of Jangouts including a testsuite and based on AngularJS 2 or an alternative framework.

Mentors: @ancorgs / [email protected] and @Imobach / [email protected]

Skills: JavaScript

Skill Level: medium

Getting started: Pick something from the list of pending features and bugs of Jangouts and try to do something about it.

Github: https://github.com/jangouts/jangouts/

Project Title: Make zypper-docker work with other package managers

Description: right now zypper-docker only works with zypper (as the name suggests). We would like to increase the portfolio and allow other package managers to interact with docker in the same way as we are doing with zypper. For this, the student will have to:

• Propose and implement a set of interfaces to abstract all the interactions with package managers and docker.
• Add other package managers than zypper.

Everything should be properly tested with both unit and integration tests.

Deliverable: zypper-docker is able to interact with images managed by apt or dnf.

Mentor: Thomas Hipp @monstermunchkin / [email protected]
Co-Mentor: Miquel Sabaté Solà @mssola / [email protected]

Skills: Go and docker.

Skill Level: Medium

Get started: You should be acquainted with the code before going for this project. For this, we recommend tackling issues with the label junior job. After that, we will ask students to give a general overview on how they are going to accomplish this feature (nothing too deep, just a general overview).

Project Title: Improve people collaboration in the Hackweek tool

Description:

The Hackweek is the time where SUSE engineers meet with other openSUSE contributors to experiment, innovate & learn interruption-free.

We want to improve the Hackweek tool to increase the colaboration inside the tool, which will lead to more colaboration outside of it as well.

First, we want to improve the comments in projects, as they are the base of communication. We should start by providing a better comment editor which helps us when writing a comment. We already support markdown, but it can be improved by supporting links for urls and rendering shorted and clickable links for other pages inside the Hackwek tool.

We also want to be able to add emojis to the comments 😻 And the most important part, we want to support mentions and notifications. Users should receive an email when being mentioned in a comment, when someone writes in one of his proposals, joins his project, etc. Every user should be able to watch / follow any project as well. A configuration page for notifications and a list of notifications will be implemented as well. Related issues: SUSE/hackweek#97, SUSE/hackweek#143

We also would like to remind users about important events, such as a Hackweek about to start, new people joining a project, etc. All this will also be rendered in the notification page. On top of that, we could have live feed of what is happening during HackWeek: comments, joins, new projects,
progress ...

Another important point to improve collaboration in all the projects is that all of them have the same visibility. Because of that we need to find a fair way to render the proposals, ensuring the all of them have the same chances to be seen while keep showing some of the most popular ones. Currently we only have into account the likes of a proposal to consider it popular, the popularity concept should also be improved. Projects can already be tagged with involved technologies (tags). We could add a tag-cloud to allow people to easily find projects they are interested in.

Last, but not least we want to give hackweeks an end_date, so the page goes into "sleep mode" automatically after a hackweek, showing a summary what happened (most visited projects,....) instead of pretending it is still hackweek16.

Deliverable: Code is merged with the necessary tests to prove each feature created.

Mentor: @DavidKang , @differentreality

Skills: Ruby, Ruby on Rails, HTML, Java Script

Skill Level: Medium

Get started:

Fork the project and get in touch with the mentors.
We recommend you to make at least one contribution to the project as that will help you to find out if this is the right project for you and to write a proposal, but you do not need to send a lot pull requests. The decision to select a student is made based on the proposal and not in the number of previous contributions. And remember that quality is more important than quantity! 😄

Project Title: Improve the UI of Portus

Description: the UI and the UX of Portus passed GSoC 2016 thanks to @msfernandes, but there is still some pending issues to be fixed, plus some new issues:

• Allow anonymous users to see the publicly available images (see #1129).
• Extend the version info as shown on the web page (see #1023).
• Perform more checks on the client side (e.g. #861).
• The help section should be its own page, so it's available offline.

Besides this, students should also provide ideas of their own.

Deliverable: the issues mentioned above should be implemented by the end of the GSoC period. Moreover, we expect students to also have implemented improvements that they have proposed.

Mentor: Miquel Sabaté Solà @mssola / [email protected]
Co-Mentor: Rafael Fernández López @ereslibre / [email protected]

Skills: CoffeeScript, CSS, Ruby on Rails

Skill Level: Medium

Get started: Take a look at our issues on Github. Try to fix some (note that there are some junior jobs, UI issues, UX issues).

We need to collect materials we can hand out to people so they can distribute them to their local universities. @ChrisBr you had a PDF somewhere right?

Distribute those to:

• openSUSE
• SUSE

Description: Jangouts is a videoconferencing solution that can be used to hold meetings with any number of participants. But currently there is no way to record those meetings in order to watch them again. That's a feature that will make Jangouts suitable for many more use cases, like online workshops. This Issue at GitHub describes some possible approaches to implement such feature.

Deliverable: A mechanism to record and play Jangouts sessions, either integrated in Jangouts itself either as an external tool that can connect to a session and produce a video out of it.

Mentors: @ancorgs / [email protected] and @Imobach / [email protected]

Skills: JavaScript

Skill Level: medium

Getting started: Pick something from the list of junior jobs of Jangouts and try to do something about it.

Github: https://github.com/jangouts/jangouts/

Description: With Machinery you can inspect Linux systems and store the collected data as a description of the system. The description can be nicely displayed and managed by Machinery. This is useful to get insight into unknown systems, debug problems, track changes, create inventories, migrate systems, and more.

Machinery collects data in sections called "scopes". There are scopes for packages, users, files not managed by RPM, and more. When having descriptions from multiple systems or from different versions of the same system it often is useful to be able to query for information across system descriptions, e.g. "give me all descriptions where package x is installed in version y".

The goal of this project is to implement a query engine in Machinery which is able to execute such queries and return results in a usable way.

There are different possible approaches to this project. There is part about designing how queries are entered and how results are displayed, mostly from a user interaction point of view. There is a part about implementing the actual query, and there is a part about optimizing the query engine to be fast and efficient. One possible implementation would be to store the system descriptions in a data base and use the query engine the data base provides. Another possible implementation could work on the raw JSON data of the system descriptions. It's up for discussion between mentor and mentee on which part to put the focus. Input and ideas are welcome.

Deliverable: An additional sub command of the Machinery command line tool, which takes a query and gives out results.

Mentor: @cornelius, @aduffeck

Skills: Ruby, RSpec, TDD, maybe data bases, maybe a compile language such as a go

Skill Level: Hard

Get started: Get familiar with the tool, use it, have a look at the code

Project Title: Printable tickets & better check-in process for OSEM

Description: OSEM is an event management app tailored to Free and Open Source Software conferences and it is developed in the Ruby on Rails web framework.
The aim of this project is to make possible to download a pdf printable ticket after registering for a conference. It should contain information about the conference (name, logo, location, etc.), ticket type, date, user name, user email, a custom description and a QR code.
We would also like to improve how the check-in is done. Currently to do the check-in someone has to mark as present in the conference one by one every user by looking for its name or email. It would be desirable to makes this process more efficient by allowing to do reading the generated QR. We also want to limit when the ticket is valid (the times, days, etc.), to register information about when the user arrive/leaves the conference and to modify the number of conference resources. Last, statistic with this information should be rendered.

Related issue: openSUSE/osem#1153

Deliverable: Printable tickets are available. The check-in can be done on a more efficient way.

Mentors: @Ana06, @mdeniz

Skills: Ruby, Ruby on Rails, HTML, Java Script

Skill Level: Medium

Get started: Pick one of the Junior labeled issues and get in touch with the mentors.

Github: https://github.com/openSUSE/osem

The GSoC timetable is something most new students don't understand. There are some hurdles they need to take and we should help them get over them with a blog.

Hi,

we are coala (coala-analyzer.org) and have not been accepted for GSoC so far. We have lots of students who already contribute to our project and really want to do a GSoC with us. We have mentorship capabilities for several projects as well and mentored two students successfully last year.

If you have need for it I'd be happy to help out administering your GSoC with my experience from GNOME. We'd love to participate under your umbrella in this GSoC.

I didn't find any IRC channel or email, if you wish to continue this as a private discussion, please write me an email to [email protected] .

Project Title: Implement the server command in zypper-docker

Description: The aim of this project is to allow zypper-docker to act as a web application. With this command, zypper-docker will provide an API in which clients will be able to check whether an image contains security vulnerabilities. Therefore, the student should do the following:

1. Propose an API.
2. Implement the endpoints of the API
3. Properly implement the backend code needed to fulfill the API.

Everything should be properly tested with both unit and integration tests.

Deliverable: zypper-docker should be able to act as a web application. Clients will be able to perform requests asking for the security status of an image and get back a proper response.

Mentor: Miquel Sabaté Solà @mssola / [email protected]
Co-Mentor: Thomas Hipp @monstermunchkin / [email protected]

Skills: Go, docker. Experience in designing APIs is a plus.

Skill Level: Hard

Get started: You should be acquainted with the code before going for this project. For this, we recommend tackling issues with the label junior job. After that, we will ask students to give a general overview on how they are going to accomplish this feature (nothing too deep, just a general overview).

I'm already in contact with two professors at TH Nuremberg and FAU Erlangen about organizing a GSoC meetup!

Hey, we have built projects.coala.io which is serving a similar purpose, I was wondering if that might help you. Joining two projects to one in some way usually means better quality and less maintenance for all parties ;)

This will be next Thursday. We need to get a short presentation together about GSoC and what people can do for it.

Project Title: Give administrators more control over Portus

Description: This project is based on multiple small tasks aimed at improving the admin control over a Portus instance.

The student is encouraged to propose new ones or improve the ones proposed below:

• Allow admins to change the ownership of a namespace across different teams.
• Allow disabling the creation of teams/namespaces for normal users
• Add "maintenance mode". This will forbid write actions.
• Add activities for:
  • Toggle admin (+ send an email)
  • Toggle enabling/disabling a user (+ send an email)
  • Creating a user from the rake task or from the admin panel
• There should be a "public/private" toggle in the namespaces#show page. Right now, this toggle only exists in the namespaces#index page (idea: maybe we can add this toggle widget on the right corner of the title of the container that has the list of repos in it)
• Allow to create tags on the web: allow re-tagging of tags that have already been uploaded

Deliverable: most of the tasks mentioned before should be merged into the master branch. Improvements to our integration infrastructure are also desirable.

Mentor: Flavio Castelli @flavio / [email protected]

Co-Mentor: Jordi Massaguer Pla @jordimassaguerpla / [email protected]

Skills: Ruby, Ruby on Rails

Skill Level: Medium

Get started: Take a look at our issues on Github. Try to fix some (note that there are some junior jobs).

Successful projects use modal for pop up divs. They have scrollbars, however they don't work (not the scrollbar itself but the scroll event). Scroll starts working after I have triggered some other event (like right click, open inspector window etc).
Can some please confirm that I am not the only one having this issue?

Project Title: Improve user experience in Open Build Service

Description:

Open Build Service, normally abbreviated as OBS, is a generic system to build and distribute binary packages from sources in an automatic, consistent and reproducible way. The openSUSE public instance is running at https://build.opensuse.org.

OBS user interface is in many cases not intuitive and difficult to use, especially for new users. There are workflows that could be improved to make users lives much more comfortable and new features that could be introduced. During the last years, the large OBS community has suggested many improvements in this regard. The objective of this project is to implement some of these ideas:

• The project monitoring page gives users an overview of all the package builds of a project, for example on the OBS:Server:Unstable page. The content of this page has been increased to the point that it is now overloaded, looks broken and is really difficult to read. During the project a better structured page will be designed and implemented. For example, icons could be used for states instead of words, build target with similar names could be condensed to tabs and the table could be replaced with individual package divs. Related issue: openSUSE/open-build-service#410.

• Currently it is only possible to upload one file at a time, which is painful when uploading many files. We want to allow uploading multiple files at once to make this task faster and less repetitive for our users. We also have a really cool feature to upload files from GitHub, but it is that hidden that nobody is using it! We want to give this feature more visibility and improve the workflow. Related issue: openSUSE/open-build-service#242

• The watchlist is used to bookmark projects. It is already a useful and very used feature, but because of that we want to improve it's usability. We want to allow give an alias to the projects there, grouping projects for long lists and indicate when you are in a bookmarked page.

• On the web site of a repository belonging to a project, there is no obvious way to add it to a package manager, such as zypper. Related issue: openSUSE/open-build-service#407

Deliverable:

The UI / UX of OBS improved:

• The project monitor page scales.
• Multiple files can be added altogether.
• Items in the project watchlist can be managed (alias handling, grouping, etc.).
• Projects provide way to choose a distribution and depending on that provide a link to the repository.

Mentors: @Ana06, @bgeuken, @ChrisBr

Skills: UI/UX knowledge, HTML, Ruby, Ruby on Rails and Java Script. Packaging knowledge would also help but is not mandatory. And the most important thing: a great desire to learn! 😉

Skill Level: Hard

Get started:

Pick one of the good first issue labelled issues and get in touch with the mentors!
We recommend you to make at least one contribution to the project as that will help you to find out if this is the right project for you and to write a proposal, but you do not need to send a lot pull requests. The decision to select a student is made based on the proposal and not in the number of previous contributions. And remember that quality is more important than quantity! 😄

Description: TSP is a Ruby on Rails based application to manage the requests and reimbursements from travel help programs of free software organizations. Originally developed for the openSUSE Travel Support Program it was adopted recently by the KDE e.V. Travel Cost Reimbursement initiative. This project is about making the tool more useful for KDE e.V. and possible future adopters. That includes:

• Implementing the new requested features
• Move the DSL used to specify the role-based permissions and notifications from the models to configuration files, so the application is easier to adapt.
• Migrate the interface from Bootstrap 2 to a newer version (or a different framework), so writing a new theme does not imply using an outdated CSS framework.
• Other improvements regarding usability would also be welcome.

Deliverable: A new version of the TSP application that covers as many points as possible from the list above.

Mentor: @ChrisBr / [email protected] and @ancorgs / [email protected]

Skills: Ruby on Rails

Skill Level: Medium

Get started: Install the application and implement something useful (with tests), like the improved search or any other feature. Fixes related to usability would be specially appreciated.

Github: https://github.com/openSUSE/travel-support-program

https://github.com/openSUSE/mentoring/wiki/GSoC-Organization-Application

Started with c&p from https://en.opensuse.org/openSUSE:GSOC_application_form

Description: openSUSE, as other distributions, includes the command update-alternatives in order to allow users to choose which program they want to be the default for every given function (which text editor, which Java implementation and so on). Being quite prominent in other distributions, update-alternatives does not get the attention it deserves in openSUSE. The project consists on implementing a YaST module for managing the alternatives and their priority, offering an easy and guided interface on top of plain update-alternatives.

Deliverable: A YaST module offering a clear overview of all the alternatives in the system and a convenient way to manage their configuration and priorities. The module must conform to the YaST development guidelines, which means, among other things, that it must include unit tests (RSpec).

Mentor: @lslezak / Ladislav Slezák and @ancorgs / [email protected]

Skills: Ruby, Rspec, Object oriented design

Skill Level: Easy

Getting started: Read the new YaST tutorial and write question or suggestions on how to improve it to [email protected] mailing list.

Github: https://github.com/yast/

Setup an IRC meeting to discuss

• GSoC Timetable
• Next steps for mentors
• How to attract students
• How to help students to write a good proposal

Description: Write a new YaST module for apache that do initial setup of apache with given framework so it allows easy start. Module is focused for newbies with basic setup. It is not intended to modify existing configuration. It should include also install of needed packages. Module use cases are:

• I want to quickly setup apache with static HTML
• I want to quickly setup apache with PHP
• I want to quickly setup apache with RoR
• I want to quickly setup apache with django
• I want to quickly setup apache with mocculus
• ...etc. with frameworks you are interested.

Deliverable: YaST module that can do initial setup with static html pages and at least one of frameworks. The module include documentation and tests.

Mentor: @jreidinger / [email protected]

Skills: Ruby, Rspec, Object oriented design

Skill Level: Easy

Getting started: Read new tutorial and write question or suggestions how to improve it to [email protected] mailing list.

Github: https://github.com/yast/

Project Title: Improve LDAP support

Description: this project is based on two main points, and an optional one:

1. Add LDAP Group support: This is better explained here.
2. Improve the current integration testing setup to include all the possible
   LDAP configurations.
3. (Optional) General improvements on LDAP handling that the student might feel
   that are needed. There should be total freedom for the student to propose
   ideas that might be interesting and deliverable for the GSoC period.

Deliverable: LDAP Group support should be merged into the master branch.
Improvements on our integration infrastructure are also desirable.

Mentor: Miquel Sabaté Solà @mssola / [email protected]
Co-Mentor Flavio Castelli @flavio / [email protected]

Skills: Ruby, Ruby on Rails, Docker.

Skill Level: Medium

Get started: Take a look at our issues on Github. Try to fix some (note that there are some junior jobs).

We should present the individual projects, what they are about and how students can start (basically a text out of the issue) on news.opensuse.org

Description: There is libyui library which provides single interface for three toolkits (QT, GTK and ncurses). It is heavily used in YaST and also Mageia uses that for its configuration tool. YaST is now transpiled to ruby and libyui ruby bindings is simple 1:1 to its C++ API. Goal of this project is to design and implement native ruby API built on top of libyui.

Deliverable: It is expected that at the end of project there will be design of library, proposal for API and implementation for basic widgets.

Mentor: @jreidinger / [email protected]

Skills: Knowledge of ruby idioms and basic ruby libraries - to have idea how good ruby design look like API design

Skill Level: Medium

Getting started: Look at existing frameworks and its API like shoes, dsl-gtk or [hello-rugui](http://blog.rugui.org/2009/01/hello-rugui/ hello-rugui/) and then post to [email protected] mailing list own proposal how new API can look like together with at least two examples of code that uses such API.

Github: https://github.com/yast/

Description: Callstats.io is a SaaS service that helps WebRTC services detect and diagnose media and network quality issues. It would be nice if companies and individuals deploying Jangouts would have the possibility to use this service in a straightforward way. This task can be completed by sending WebRTC events and measurement data from the Jangouts application and the Janus media server in real-time to callstats.io. The developer is expected to integrate the callstats.io REST API with the WebRTC components in Jangouts and Janus. The Jangouts app will send endpoint stats and Janus will send the stats related to the WebRTC gateway.

Deliverable: A new configuration option in Jangouts (maybe even needing explicit acceptance for the participant to be really enabled) to activate the optional callstats.io integration. If enabled, it will show the stats on the callstats.io dashboard from the Jangouts endpoint and the corresponding Janus server.

Mentor: @ancorgs / [email protected] and [email protected]

Skills: JavaScript and C.

Skill Level: Medium

Getting started: Pick something from the list of junior jobs of Jangouts and try to do something about it. Also check the callstats.io documentation.

Github: https://github.com/jangouts/jangouts/

Description: The Open Source Event Manager is an event management app tailored to Free Software Conferences, it is developed in the Ruby on Rails web framework. We have several ideas to enhance the visitor experience. First of all, the event schedule isn't mobile friendly and and there is no way to have several schedule proposals to compare before releasing it (see openSUSE/osem#18 & openSUSE/osem#587). Furthermore we would like to gather feedback from the conference visitors (see openSUSE/osem#549) and improve our conference splash page (openSUSE/osem#400).

Deliverable: Reworked and mobile friendly schedule and splash page. Some way to gather user feedback

Mentors: @ChrisBr @hennevogel @differentreality

Skills: Ruby, Ruby on Rails, HTML, Java Script

Skill Level: Medium

Getting started: Pick one of the Junior labeled issues and get in touch with the mentors.

Github: https://github.com/openSUSE/osem

Project Title: Create awareness for openQA's environment during screen recognition

Description: OpenQA works like an user, that is constantly interacting with a computer, and using a set of pre-defined instructions and looks at the screen every certain ammount of time, to check for reference image, and asks "Does this screen that I'm looking at, match this screenshot? if so, how much? are they similar? how similar? is there any better match?", this is called needle matching, and it's key to openQA's operation.

Currently in openQA you can create needles and assign certain tags, so you can use in the test code certain things that allow you to categorize the content, however there is a need for these screenshots to be tagged better or at least be made aware of their relevance, since a test distribution can be large and span across multiple versions, we would like to allow our test developers to say "Ok, all the needles that have 'certain' tag, are not relevant anymore, therefore they should not be used for a specific version".

How this can be done? maybe by analyzing the database?, by offering an UI component that allows the selection of certain needles based on different statistics like usage? or by build?

The idea includes few different things that should be done:

• Learn what openQA/script/modify_needle does and can do
• Improve the statistics for the needles.

Deliverable: An extension to '/admin/needles' or an external tool is provided, with documentation and corresponding integration tests.

Mentor: @foursixnine, @mudler, @coolo

Skills: Go, Perl, Python, HTML, Javascript, UI/UX

Skill Level: Easy/Medium

Get started:

• You can start looking here: https://progress.opensuse.org/issues/13950
• Start forking the openQA and os-autoinst
• Engage with the development team! We hang out in #opensuse-factory on freenode irc net

Description: With every new release of Jangouts or every time we want to update the version of Janus Gateway deployed in our servers, we need to ensure everything still works with several browsers (and several versions) in various operating systems. That's something that should be automated (in the same way that we already have some Jasmine-based unit test for the internal Jangouts components). This project is about researching about the possibilities and designing some solution that allows to automatically verify if Jangouts works by firing some web browsers, connecting them to a Jangouts instance and checking that the browsers can communicate through it.

Deliverable: A piece of software that can run or emulate several browsers with their own virtual cameras/microphones joining to a Jangouts room. Desirably with different versions of each browser. The tool should report whether a given Jangouts instance is working as expected.

Mentors: @imobachgs [email protected] and @ancorgs / [email protected]

Skills: JavaScript. Testing

Skill Level: hard

Getting started: Pick something from the list of junior jobs of Jangouts and try to do something about it.

Github: https://github.com/jangouts/jangouts/

Description: The Open Source Event Manager is an event management app tailored to Free Software Conferences, it is developed in the Ruby on Rails web framework. OSEM already has a feature to sell conference tickets. At the moment the user has to buy the ticket online and pay on arrival at the conference. We would like to have a way to purchase and pay online.

Deliverable: Workflow to support online payment of conference tickets.

Mentors: @ChrisBr @hennevogel @differentreality

Skills: Ruby, Ruby on Rails, HTML, Java Script

Skill Level: Medium

Getting started: Pick one of the Junior labeled issues and get in touch with the mentors. Furthermore have a look at the Stripe and Active Merchant APIs.

Github: https://github.com/openSUSE/osem