#summary Ideas for Google Summer of Code students #labels Featured,Phase-Design = Introduction = This page lists some of the ideas we've come up with that students could tackle for a [http://code.google.com/soc/ Google Summer of Code] project. Proposals can be made based on items in this list, or you can propose something entirely new. You can also look at our bugs marked [http://code.google.com/p/reviewboard/issues/list?can=2&q=label:ExtensionIdea ExtensionIdea] for more ideas. = IDE Integration = Add support to Visual Studio, Eclipse, or another popular IDE to work with Review Board. At a minimum this should support: * Posting/updating review requests * Viewing the user's existing review requests and changing their statuses * Applying a change from a review request to the active codebase. This could be extended for more advanced functionality, including: * Inline commenting on diffs within the IDE (possibly through a browser plugin, or through the IDE's code editors themselves). * Looking at pending changes to an active file. Most of this functionality will be in the IDE plugin itself, but some will be to Review Board (such as adding new API for accessing this information). = Windows Installer = Add a new, all-encompassing Windows Installer. The installer would install Review Board and its dependencies, optionally installing Python, Django, Apache, MySQL, or whatever based on the user's preference and existing installed services. In most cases, installing dependencies will simply require automating the download of an existing MSI file on the web. Some dependencies, however, may need to be packaged by us. The installer must be an MSI installer, based on [http://nsis.sourceforge.net/ NSIS]. There's some base work done on this to get you started. = Linux/Cross-Platform Installer Framework = Provide an extensible Linux installer that can handle getting Review Board up and running on most popular distros (Red Hat Enterprise Linux, Fedora, Debian, SuSE, Ubuntu). This should be able to determine what packages are installed, install new packages (perhaps from third party package feeds where appropriate). The goal is to be able to run one script and get Review Board installed. However, this should go beyond just getting Review Board up and running. It should also handle the following: * Provide a cross-platform UI library for interactions (GTK+, terminal, possibly Windows) * Provide a Python module for querying what's installed, performing installs and upgrades, etc. This should interface with easy_install and the system's package manager where possible. * Support managing third party packages for Review Board. This will be important for extensions when we land that in SVN. = Diff Analysis, "Moved" regions, and Filtering = Add the ability to analyze an upload diff in the background. This should do the following: * Record the number of adds/deletes/replaces, for use in the diff viewer's changed files list. * Find blocks of deletes that match blocks of inserts and mark them as "moves," based on some minimum line count. Update the diff viewer to link between these sections. * Find common changes (such as a variable rename) and mark them. We could then use this information to filter out such changes, turning large reviews into smaller ones. = Policy Support = Provide a flexible framework for defining custom policy across Review Board. This should cover the following: * Only allow users to view review requests in groups they belong in. * Prevent users from joining arbitrary groups. * Requirements for closing a review request. This should be flexible enough to allow administrators to define rules such as requiring all target reviewers to review it, or some minimum number, or some percentage, and handle such attributes as the number of "Ship Its." There's more that may be needed here. Part of this will be to ask companies on our mailing list for their requirements, and forming a strategy with us based on these requirements. = Tighter Project Tools Support = In order to better integrate Review Board with other tools, we should add tighter repository integration. It should be trivial to get to the listing for a file in a repository browser (say, on Trac) through the diff viewer, or post review requests based on committed code in a repository. We should also improve the admin UI to make it easier to associate a repository URL or a bug tracker URL without the user having to type the full path. For example, they could type the path to the trac repository and select "Trac," and the admin UI should do the rest. = Theme Support = Giving users the ability to customize the look and feel of Review Board means that companies can better integrate the tool into their existing infrastructure, and open source projects can provide one navigation bar across their site, Trac (or whatever), and Review Board. Part of this is to clean up the templates such that they can be extended by theme templates without breaking existing functionality. The actual theme support itself must also be developed and put into our Djblets library. = Improved Admin UI = The administration UI should be rethought and should offer more hand-holding to get started with Review Board. It should easily walk new administrators through setting up repositories, linking them to bug trackers, customizing the settings, etc. Something like a task-based UI might work for this by offering a side panel of things the administrator might want to do. Another thing to look at would be WordPress's new administration UI. It should also be easy to see an overview of what's happening on the system, such as the number of logged in users, load on the server, memory usage, etc.