On Thu, 2007-03-22 at 13:36 -0400, Andrew Overholt wrote: > * Toshio Kuratomi <a.badger@xxxxxxxxx> [2007-03-21 20:38]: > > > > Trying to do the whole thing as a SoC project is, I think, overzealous. > > I'd like to see a definition of what we want to achieve and what > > existing systems it will tie into. > > I was envisioning just the review process itself for a SoC project. > Yah. My point is that this ties into a lot of other projects, some finished and some ongoing. What are the goals of the web app? To move away from bugzilla? Which features in particular are not meeting our needs on bugzilla and which does bugzilla do well? What do we want to do with the data from reviews? If we tie this into preapproval builds, do we have to do reviews of untrusted packages before submitting to mock or is mock sufficiently secure to do a build up front? Work done on moinmoin, or backup software in previous iterations of the SoC were largely independent of what we do with the rest of Fedora. A Review Web App sits squarely in the middle of it. The mentor for this project needs to be aware of where they want the application to connect to other Fedora services and how it's supposed to improve on the current experience. Which is not to discourage you from pushing this as a project. Bugzilla has shortcomings as a reviewing location. But there's more to this than a better UI. Defining what the app needs to solve will allow for defining what a successful project will look like rather than sticking some poor student in the middle of a bunch of competing interests with no clear idea of what they need to do to create some software that we'll be able to start using when they're done. -Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
