[RFC] A new page listing the user's patches that are waiting for feedback

[Guilherme Salgado]

On Thu, 2011-04-07 at 09:23 +0800, Jeremy Kerr wrote:
> Hi Guilherme,
> 
> > Given the above, I'm kind of leaning towards not using the existing
> > generic_list() helper and omitting the filters, the form to bundle
> > patches and the Delegate field from the Properties form. This would make
> > sure we don't mislead users into doing things that won't actually work
> > as they expect, but it also leaves the ability to change the state
> > and/or archive patches, which I think is quite useful.
> 
> I've wanted to add a 'my patches' view previously, so thanks for taking
> a look at this. However, the multiple-projects-on-one-list part does
> make this a bit difficult.
> 
> Would separating the patches by project still work for you?

I think it would not be ideal for our use case, but it is probably good
enough and I'd be prefer to work on something that has a chance of being
accepted, so I'm willing to give it a try.

> 
> I'd imagined implementing this by:
> 
>       * Adding a "my patches for $project" view, which should just be a
>         matter of configuring the filters correctly. Other than the
>         submitter filter, the other filters would have the usual default
>         settings, and be changeable via the UI. This means that we get
>         the "action required" patches by default, but the user can still
>         get the full list easily.

AFAICT, the submitter filter will match against the person name or id,
which is not going to match all my patches if the names of all Person
entries associated with my user are not identical.

We could try and make the filter match against either a person or a
user, but I think a UI for that would be confusing.  Or we could make it
match against the user linked to the selected person when there's one,
but this may not be what everybody expects (e.g. they may want the
ability to search patches submitted using just one of their email
addresses).

> 
>       * Changing the 'contributor to...' text at the top of the
>         userprofile view to something (a table?) listing the numbers of
>         patches in an action required state. Project names would be
>         links to the "my patches for $project". This gives a quick
>         overview of patches in all projects.

Indeed, that'd be an important thing if we have separate lists per
project.

> 
> The downside of this is that if a user is participating in multiple
> projects, they need to visit multiple pages if they want to see the list

Exactly; that's the main reason why I went with a single cross-project
list.  All patches submitted upstream by Linaro engineers will end up in
our patchwork instance, so there's a big chance that most people will
have patches in a few different projects.

It also means users have just one URL to bookmark or type instead of
having to go to the profile page and follow links from there.

> of all patches. However, I think this is okay, for a few reasons:
> 
>       * Although users may be contributing to multiple projects, it's
>         likely that only one or two would be their main focus of
>         attention at any one time.

In our case there are a bunch of cases where there are more than one or
two but as long as it's less than a handful (which seems to be the case
for everyone so far) it should be fine.

> 
>       * Cross-posting a patch to multiple (patchwork-enabled) projects
>         would results in multiple entries on the 'my patches' page, only
>         one being relevant. Cross-posting a series of patches will make
>         this unusable, unless we can then filter by project.

I don't think this is much worse than when you have one list per project
-- you'll still see them all, just on multiple lists instead of on a
single one.

> 
>       * With the current patchwork installations, the projects on each
>         server (patchwork.ozlabs.org/patchwork.kernel.org/others) may
>         not have any specific grouping; this puts the 'my patches' into
>         fairly arbitrary groups.

In practice the only grouping is for the projects you contribute to,
which seems to be a reasonable thing to me. If you don't contribute to
most of the projects in a given patchwork instance, then you'd see no
trace of them on your 'my patches' view.

Another downside of this approach is that it makes it harder to find a
given patch by skimming through the list. Supposing you know on which
project the patch is, you can go straight there and there will probably
be less patches for you to skim through.

-- 
Guilherme Salgado <https://launchpad.net/~salgado>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/patchwork/attachments/20110407/369bfd0a/attachment.pgp>