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.
  Ex : when someone claims to work on a bug for pitivi, he assigns
himself the bug (by switching it to ASSIGNED). If you can figure out a
way to properly inform the upstream bugtracker (not just for pitivi but
for all bugtrackers) then I think it would be very doable.

> * 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 ?

> * We give it *lots* of publicity -- with help from you guys reaching
> Planet Gnome

  No problems with 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.

> 
> The idea is very similar to "PiTiVi Love" but dressed up to be super
> friendly for newbies, and wrapped inside of a contest.You can read
> more on our wiki, http://openhatch.org/wiki/Starling

  Once again, excellent ideas for newcomers, I'm all for it. And if I
understand correctly, this could be a very good way to introduce
newcomers to various projects... which would then migrate to the
upstream system once they're familiar with it.

  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.

> 
> We want PiTiVi to be among the very first projects because we kinda like it 
> (-:
> 
> What do you guys think?

  Maybe grabbing all the pitivi-love tagged bugs on bugzilla would be a
good way to start ? Jeff ?

   Edward
  
[1] I mean the pitivi 'product' site/page on launchpad, not the pitivi
'package' site/page (which is perfectly normal for distros).

P.S. No, I don't *hate* launchpad. I just think it's going out of it's
duties boundaries and getting on many people's (i.e. upstream) nerves.
> 
> Thanks,
> .danny
> 
> ------------------------------------------------------------------------------
> 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



------------------------------------------------------------------------------
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

Reply via email to