On Thu, 23 Sep 2010, Edward Hervey wrote: > Hi, > > On Wed, 2010-09-22 at 16:10 -0400, Danny Piccirillo wrote: >> Hello all! >> >> I'm working with OpenHatch on a project called "Starling Bounties." >> We're trying a strategy to help projects get new contributors, and we >> want PiTiVi to be among the very first. I brought this up on IRC >> already, but anyways, here's how it works: > > Very interesting idea :) > >> >> * The PiTiVi community selects a few bugs to nominate (together, we >> will pick a single one, in this thread) that should be good for >> newbies to tackle. On IRC, we all got excited about Bug 615570 >> * The PiTiVi development community commits to not working on that bug >> for the duration of the bounty, around 14 days > > It would be nice if there was some *easy* way to avoid the whole > unofficial (launchpad) vs official (bugs.gnome) bugtracker issue.
OpenHatch doesn't create "unofficial bug trackers" like you're worried about. We do have http://openhatch.org/search/ but that updates nightly from GNOME Bugzilla -- it's a read-only snapshot. This initiative, we can ask the person to assign to himself/herself in Bugzilla while he/she's working on it. It'll really be a blog post with a comments thread, not a "bug tracker". >> * We write a blog post describing the bug and documenting how to go >> about fixing it with a step-by-step walkthrough > > Same issue, how are you going to solve the duplication of information > between your system and the official bugtracker ? Our "system" is just the comments section of a blog post. (-: Going forward, if this works, we *might* create some technology for managing it. And your concerns about synchronization are very important if we do that. >> * Whoever leaves a comment claiming the bug gets a lock for 48 hours. >> If they submit a patch, the PiTiVi community must review it within 24 >> hours, and if it works, should commit it! And then we say thanks and >> we (and you guys) write a follow-up blog post welcoming the new >> contributor into PiTiVi. > > 48 hours can be really short for solving some bugs, Jeff summed up > most of the issue about that in his mail. > Putting that time limit in your system makes sense, but I wouldn't > stop it having multiple proposals if we take a bit more time reviewing > the patches. You're right. Hey, so -- What bug are we going to use? And then once we figure that out, what should we set the lock duration to? > the *only* thing I want to avoid, and I won't be able to stress this > enough, is to avoid disparity between places to hack on a certain > project. > Launchpad [1] is a perfect example of what *not* to do, a lot of > people think the bzr pitivi branch is the official repository, that the > launchpad bugtracker is the official one, that the launchpad translation > system is the official one, etc... Which causes massive waste of time > for upstream (because we don't have time to check multiple locations for > bug reports, translations, patches) and contributors (because they don't > get their proposals, bug reports, etc... looked at as often). > > As long as you avoid that and stick to a nice entry point for > newcomers to make it easy to find things to hack on for various projects > and make the relationship with upstream clear and unambiguous... I'm > fine with it. Totally agreed! And keep us in check -- I hope the details I'm providing explain that we're not causing this problem. -- Asheesh. -- Be different: conform. ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Pitivi-pitivi mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pitivi-pitivi
