Re: PR duty
On Thursday, 5 April 2018 at 17:59:40 UTC, Jack Stouffer wrote: On Wednesday, 4 April 2018 at 05:31:10 UTC, Andrei Alexandrescu wrote: ... We can certainly try it, I'd be interested to see it's impact. The biggest problem Phobos is facing at the moment is total number of reviewers. Strangely and just in Phobos there are also 22 opened and approved PR.
Re: PR duty
On Wednesday, 4 April 2018 at 05:31:10 UTC, Andrei Alexandrescu wrote: Hi folks, I was thinking of the following. To keep the PR queue trim and in good shape, we'd need at least one full-time engineer minding it. I've done that occasionally, and the queue size got shorter, but I couldn't do much else during that time. I was thinking, we can't afford a full-time engineer, and even if we did, we'd probably have other important matters for that engineer as well. However, what we can afford - and indeed already benefit from - is a quantum of time from each of many volunteers. By organizing that time better we may be able to get more output. Here's what I'm thinking. Let's define a "PR duty" role that is one week long for each of a pool of volunteers. During that week, the person on PR duty focuses on minding github queues - merge trivial PRs, ping authors of old PRs, email decision makers for specific items in PRs, etc. Then the week ends and the role is handed off to the next person in the pool. (...) Thanks, Andrei Maybe one idea would be to get university people interested in D. A lot of work on the Scala compiler and eco system is done by students at the technical university of Lausanne where Martin Odersky (the creator of Scala) is teaching. They do work on it in their master or PhD thesis or just help on the development of tools and libraries. The EPFL is well endowed with money and pays as long as the work being done is in some way research oriented (and as long as Scala is a big thing in the IT world). So the idea would be to get some university professors interested in D. Then you have people working on D and its eco system that are paid by the university or do the work for their thesis. I would say that D is ideal for teaching programming being a high-level language with both manual memory management and a GC. It's really a win-win situation for D and teaching institutions. So I would propose to have a look at universities/academia as a new target to promote D. Students one day finish their studies and then take the language with them from which they learned a lot and know very well ... ;-).
Re: PR duty
On Wednesday, 4 April 2018 at 05:31:10 UTC, Andrei Alexandrescu wrote: Hi folks, I was thinking of the following. To keep the PR queue trim and in good shape, we'd need at least one full-time engineer minding it. I've done that occasionally, and the queue size got shorter, but I couldn't do much else during that time. I was thinking, we can't afford a full-time engineer, and even if we did, we'd probably have other important matters for that engineer as well. However, what we can afford - and indeed already benefit from - is a quantum of time from each of many volunteers. By organizing that time better we may be able to get more output. Here's what I'm thinking. Let's define a "PR duty" role that is one week long for each of a pool of volunteers. During that week, the person on PR duty focuses on minding github queues - merge trivial PRs, ping authors of old PRs, email decision makers for specific items in PRs, etc. Then the week ends and the role is handed off to the next person in the pool. A calendar maintained by an impartial person - maybe we can ask Mike - would keep track of everything. On the actual topic of the thread, the scrum master for this sprint could have some of these duties rolled in as well. Therefore, for a given sprint, they would be in charge of: - taking care of trivial PRs - pinging authors of old PRs(?) - email decision makers - make sure previously decided-upon action items are taken care of before the next sprint - being a central point of contact for questions on items for that sprint - generally being available on Slack and coordinating the team I wonder if the Github bot can be configured to automatically tag new items for the next sprint... Also, I put a question mark beside "pinging authors of old PRs" because that seems like something the bot could also do automatically (maybe ping every 2 weeks, and if the submitter has not responded after 3 pings it's auto-closed).
Re: PR duty
On Thu, Apr 05, 2018 at 09:42:50PM +, Meta via Digitalmars-d wrote: > On Wednesday, 4 April 2018 at 05:31:10 UTC, Andrei Alexandrescu wrote: > > Hi folks, I was thinking of the following. > > > > To keep the PR queue trim and in good shape, we'd need at least one > > full-time engineer minding it. I've done that occasionally, and the > > queue size got shorter, but I couldn't do much else during that > > time. [...] > Something adjacent but related that I've been wanting to suggest for > awhile is that we hold a semi-weekly or weekly scrum for Phobos and/or > dmd (with possibly overlapping but not necessarily identical groups). > > I'm thinking that you would attend the Phobos one and Walter the dmd > one (I don't think it'd be necessary to have you at _every_ meeting). > The idea is that we go over each PR opened that week and decide what > to do with them (merge, close, needs guidance, needs W/A decision, > etc.) The scrum master that sprint (which could rotate between people) > is responsible for getting a decision from you or Walter on items (if > you're not at the scrum), ensuring action items are followed up on by > those they're assigned to, just generally coordination and > administrative tasks... > > The goal is to improve the team's velocity such that we are handling > every PR that comes in for that week, and then start eating into the > backlog. IMO that backlog should be prioritized, but I'm not certain > how to go about that yet. [...] One thing I've done in the past when I got some spare time was to plunge into the oldest end of the PR queue (just go straight to page 4 or page 5, or sort by least activity, etc.) and look for PRs that have stalled. The "stalled" tag helps find them easily, but I've found that the most profitable PRs are the ones that non-controversial, i.e., don't have other tags that implies some complexity (e.g., blocked, needs work). "Needs rebase" is generally a good tag to target. Once such PRs are identified, dig into why they've stalled: quite often, it's because somebody dropped the ball (original submitter stopped working on it, or reviewers overlooked it, or it needs a rebase because a conflicting change was committed). In the case of rebase, since github lets us have write access to PRs, it's often quite easy to just pull the PR locally, rebase it yourself, and push the changes back. (Sebastian has a very nice how-to on the wiki documenting how to do this.) In the case the ball was just dropped, just ping the submitter / a random bunch of Phobos reviewers to get things going again. If there is no response for about a week or so, ping again. In general, these PRs are your excuse to make a pest of yourself and bother people until they start doing something again. :-P The last time I did this, I managed to declog about 15-20 PRs over a course of 2-3 weeks (dropped the PR queue to <100). But I got too busy to continue, and since that time the PR queue has lengthened again. So it's an ongoing battle. But if say we had 2-3 people doing this on a regular basis (you don't even need commit access if you're just pinging people), I think we can easily get the PR queue size under control again. My personal goal was to push it down to <50 -- we actually managed to do that once, a few years back, we almost got it down to one page, but then one of the people involved quit contributing to Phobos and things started piling up again. T -- He who sacrifices functionality for ease of use, loses both and deserves neither. -- Slashdotter
Re: PR duty
On Wednesday, 4 April 2018 at 05:31:10 UTC, Andrei Alexandrescu wrote: Hi folks, I was thinking of the following. To keep the PR queue trim and in good shape, we'd need at least one full-time engineer minding it. I've done that occasionally, and the queue size got shorter, but I couldn't do much else during that time. I was thinking, we can't afford a full-time engineer, and even if we did, we'd probably have other important matters for that engineer as well. However, what we can afford - and indeed already benefit from - is a quantum of time from each of many volunteers. By organizing that time better we may be able to get more output. Here's what I'm thinking. Let's define a "PR duty" role that is one week long for each of a pool of volunteers. During that week, the person on PR duty focuses on minding github queues - merge trivial PRs, ping authors of old PRs, email decision makers for specific items in PRs, etc. Then the week ends and the role is handed off to the next person in the pool. A calendar maintained by an impartial person - maybe we can ask Mike - would keep track of everything. The most obvious candidates for PR duty engineers would be the most prolific contributors in the respective repositories. One question would be how many distinct pools/tracks we should have. Presumably someone fluent with phobos is not necessarily fluent with dmd. So probably we need at least two tracks: * dmd * everything else (druntime, phobos, tools, site) If there are a dozen of us in each pool, each would be on duty one week every three months. Even with eight, we'd be on duty a manageable week every other month. Please share your thoughts. Thanks, Andrei Something adjacent but related that I've been wanting to suggest for awhile is that we hold a semi-weekly or weekly scrum for Phobos and/or dmd (with possibly overlapping but not necessarily identical groups). I'm thinking that you would attend the Phobos one and Walter the dmd one (I don't think it'd be necessary to have you at _every_ meeting). The idea is that we go over each PR opened that week and decide what to do with them (merge, close, needs guidance, needs W/A decision, etc.) The scrum master that sprint (which could rotate between people) is responsible for getting a decision from you or Walter on items (if you're not at the scrum), ensuring action items are followed up on by those they're assigned to, just generally coordination and administrative tasks... The goal is to improve the team's velocity such that we are handling every PR that comes in for that week, and then start eating into the backlog. IMO that backlog should be prioritized, but I'm not certain how to go about that yet. Anyway, end result is that hopefully we get the queue down and are for the most part just handling new PRs each week. A big component of this is you being available for, say, at least one meeting a month. That being said, one big stumbling block I see is people being located in wildly different timezones, such as Sebastian in Germany, you on the east coast, Mike in Korea, etc.
Re: PR duty
On Wednesday, 4 April 2018 at 05:31:10 UTC, Andrei Alexandrescu wrote: ... We can certainly try it, I'd be interested to see it's impact. The biggest problem Phobos is facing at the moment is total number of reviewers. There have been, in the past few weeks, three people reviewing PRs with regularity, with more people popping up occasionally. I totally understand that people are busy, but it's near impossible to keep up with that many reviewers. The main reason the PR queue is so long for Phobos right now is we are way ahead of 2017 H2's pace with an average of 15 PRs merged per day vs 9.3, mainly due to the pace of people creating new PRs. We've been falling behind this past month with only 5 merged per day on average, while the number of new PRs didn't slow down, which allowed the open PRs to ballon to over 120. I think that more organization might help keep more reviewers involved.
Re: PR duty
On 04/04/2018 5:31 PM, Andrei Alexandrescu wrote: Hi folks, I was thinking of the following. To keep the PR queue trim and in good shape, we'd need at least one full-time engineer minding it. I've done that occasionally, and the queue size got shorter, but I couldn't do much else during that time. I was thinking, we can't afford a full-time engineer, and even if we did, we'd probably have other important matters for that engineer as well. However, what we can afford - and indeed already benefit from - is a quantum of time from each of many volunteers. By organizing that time better we may be able to get more output. Here's what I'm thinking. Let's define a "PR duty" role that is one week long for each of a pool of volunteers. During that week, the person on PR duty focuses on minding github queues - merge trivial PRs, ping authors of old PRs, email decision makers for specific items in PRs, etc. Then the week ends and the role is handed off to the next person in the pool. A calendar maintained by an impartial person - maybe we can ask Mike - would keep track of everything. The most obvious candidates for PR duty engineers would be the most prolific contributors in the respective repositories. One question would be how many distinct pools/tracks we should have. Presumably someone fluent with phobos is not necessarily fluent with dmd. So probably we need at least two tracks: * dmd * everything else (druntime, phobos, tools, site) Compiler specific stuff, system specific and finally general e.g. bindings may need to be separated roles for druntime. Compiler specific can merge with dmd, that just leaves system and "other" which probably can be merged.
