Making it easier for people to work with upstreams

[komputes]

Jorge O. Castro wrote:
> At UDS we had a discussion on how people can be better "upstream
> contacts". This is that person that picks their favorite little app
> and does their best to work with an upstream to get the bugs to the
> right place. I've started to put together a little "best practices"
> guide for people who want to do this kind of thing:
> https://wiki.ubuntu.com/Upstream/Contacts
>
> This person could be a person who is just doing general bug work, or
> someone who wants to work on a specific application. Since many of you
> tend to do this kind of work already I was hoping for some feedback on
> this page and see if it matches up with the kinds of things you might
> be talking to upstreams about. The idea for this page is if someone
> who wants to make Foobar better then they have a general idea of what
> kinds of things they can do to help move bugs along. Thoughts?
>   
> On Mon, Jan 11, 2010 at 11:25 AM, Sense Hofstede <sense at qense.nl> wrote:
>   
>> I hope I'm not disturbing someone's precious plans right now, or am
>> repeating things that are already planned. However, I would find it a
>> waste if something like Adopt-a-Package would disappear because of
>> this, and I would find it bad when there would exist two different
>> structures with the same purpose next to each other.
>>     
>
> As far as I understand it the UpstreamContacts bit is a subset of
> Adopt-an-Upstream. Daniel?
>
>   
Jorge,

My feedback...

= Adopt-a-Package =

Adopting an entire upstream (as mentioned in the above
'Adopt-an-upstream') in *most* cases is a very large job (unless the
upstream only has a few projects, or one project). I would suggest that
we continue via the "Adopt-a-Package" initiative where every bugsquad
member who wants to better an application/package can focus attention on
said package, its bugs/answers and its upstream BugTracker/IRC/Mailinglist.

Personal idea: I would not restrict this to "1 package per user" either
since more eyes will find a solution quicker and letting bugsquad
members decide what they can handle shows that we care and appreciate
that they can put their interest in any (and as many) project they feel
is worth their time. In time, and in certain projects this will grow to
be a group of people (AdoptionTeam) adopting a package.


= Upstream Contacts =

There is nothing wrong with keeping one foot in an Upstream and one in
Ubuntu, and becoming a reliable Liaison Officer between an upstream and
a distribution. Call it what you will: Liason, Bridge, Upstream Contact
- Keep in mind this is not a position *anyone* should be able to take
on, and definitely is not a task that can be picked up in a few days by
a novice willing to help.

If plans go forward, and this does in fact happen, it should be assigned
by council and not self-assigned. The person selected should be an
Ubuntu member and be involved in development upstream. I will quote a
statement on the wiki at this point, as I completely agree:

"It would be nice if upstream projects had an 'Ubuntu person' who cared
about that project and its standing in Ubuntu"

This statement is true (yes, it would be nice,) but is not always
possible. For the cases where it is not possible to find an upstream
developer who wants to be the contact for Ubuntu, then I think an Ubuntu
Member (already in BugSquad and BugControl) who has proved themselves
through the adoption of most packages in said upstream, should become
*the* Liaison Officer for that upstream. This position *would* be a
1-to-1 relation.

The person should voluntarily want to be the Liaison Officer (knowing
fully what responsibilities they are taking on) and be voted in by
council after having been carefully reviewed.


= Some extra notes =

1) Where I disagree with the wiki: "This kind of role doesn't
necessarily need to be technical."
-For a 'Package Adopter' this is true
-For a 'Liaison Officer' this is false (lots of patchwork and
development involved)

2) Worspaces can be used for Liaison Officers to delegate required tasks
to Package Adopters and BugSquad Members

3) Most of what you mentioned on the wiki should be done by 'Package
Adopters'.
This includes: bug ownership, stale bug checking, testing, version
tracking, patch notifying, sync requesting, upstream updating, schedule
notifying, IRC presence, mailing list presence.

4) 'Liaison Officer' should be involved in more high level actions and
decisions.
This includes: patch review, going to upstream sprints, going through
top bugs and working/coordinating to release fixes.

= Final notes =

I hope that Jorge and BugSquad members will agree. I would love to get
feedback on this concept.

I also think this will give some much needed structure to the
https://wiki.ubuntu.com/Upstream/ page and sub-pages.

I sincerely thank you for your time.

-komputes

  (]( -. .- )[)