[gmx-developers] Changes without reviews

[Eric Irrgang]

This topic seemed to be getting some discussion at the end of the
second-to-last dev telco, but I had to miss the last telco. Are there
any new ideas on this front? Is there any consensus on guidelines for
delegating, claiming, or avoiding code review involvement? Or (for
contributors) for understanding the status of a change in the review
process?

Before responding, I tried to look for any standing documentation on
managing tracked issues and development priorities, but I couldn't
find much. [This
page](http://manual.gromacs.org/documentation/2019/dev-manual/contribute.html)
and/or [this page](http://manual.gromacs.org/documentation/2019/dev-manual/change-management.html)
in the developer guide seems like at least a starting point for
recording additional conventions, guidelines, or policies.

On the question of tracking the level of interest/activity of a
contribution: I have very occasionally seen Gerrit changes "Abandoned"
by non-authors, but there is not really a pattern akin to "rejecting a
PR." There is a little bit more feedback on the intentions of the core
team when Redmine issues are updated. Is there a plan to expand that
feedback mechanism or to provide some other formal milestone tracking
or roadmap?

More to the point of the Gerrit dash board, it seems like there is
some user-customizability that GROMACS could provide suggestions for.
I see that Gerrit has a concept of "topics" that appear in change
descriptions and are searchable, but I don't see how to add a sortable
column, such as through https://gerrit.gromacs.org/settings. There is
also not a clear path to document these topics or map them to anything
on Redmine, to my knowledge. However, it does look like it is easy to
add custom searches to the "Your" menu. Redmine parent issues or
milestones could include proposed topics and search syntax to help
people track issues of interest regardless of staleness.

It sounded like one general preference was for Gerrit users not to use
their presence in the Reviewers list as a mechanism for tracking
progress on an issue they weren't actively reviewing. I'm trying to
figure out how to set up my Notifications preferences to trigger based
on `is:starred` or `is:watched`, but (a) the Add button doesn't seem
to be reacting, and (b) I can't figure out how I ever marked anything
as "watched." If anyone has any pointers, I will happily update my
review workflow and update the afore-mentioned documents for
posterity.


On Wed, Feb 20, 2019 at 3:44 AM Schulz, Roland <roland.schulz at intel.com> wrote:
>
> > Before people get too active in removing old stuff - is that always what we
> > want?
> >
> > One *good* aspect with anybody being able to upload pretty much anything
> > is that it also serves as a repository others can use to have a look at such a
> > change, comment (even if it's still very far from actually making it into the
> > master branch), or simply sharing development.
> >
> > If we want to go the route of only having "prime" patches show up in Gerrit,
> > we also need a strategy for where everything else should go - and then we
> > might end up with a synchronization problem between the two places
> > instead.
>
> When it comes to changes the owner has stopped working on I don't think this is a problem. An abandoned change isn't deleted. It is still available in gerrit, can still be linked to from redmine, and can still be searched. If someone wants to abandon a draft (but keep a record) they just need to publish and then abandon. Note that makes it visible to everyone.
>
> When it comes to new changes which aren't ready. I think we already have a convention for that. Prefix those with WIP. Also don't ask for review until you want to have review. That way it doesn't show up in the dashboard.
>
> > It won't - but I think that's a task management issue, for which we should use
> > a task management tool.  We spent a bunch of time evaluating different
> > tools for a recent EU project, and for the software side of things we suddenly
> > realised we have such a tool already: redmine :-)
>
> In my experience that works even less. In most cases when I post something to redmine it doesn't get any response until I link to it from gerrit. And given it gets a response when linked to, I assume, that this usually has more to do with no one noticing rather than no interest. It seems we have currently two place which gets a lot of attention. The first page of open changes and the mailing list. We tend to use the mailing list very rarely, and we advertise our wish for review by rebasing. The later doesn't seem ideal for either reviewer or owner. If we want to move this more to redmine we have to find a way to also move attention from gerrit to redmine.
>
> Roland
> --
> Gromacs Developers mailing list
>
> * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers or send a mail to gmx-developers-request at gromacs.org.