• Andrei Alexandrescu (29/29) Apr 03 2018 Hi folks, I was thinking of the following.
• rikki cattermole (5/35) Apr 03 2018 Compiler specific stuff, system specific and finally general e.g.
• Jack Stouffer (17/18) Apr 05 2018 We can certainly try it, I'd be interested to see it's impact.
• user1234 (3/9) Apr 08 2018 Strangely and just in Phobos there are also 22 opened and
• Meta (27/59) Apr 05 2018 Something adjacent but related that I've been wanting to suggest
• H. S. Teoh (37/62) Apr 05 2018 [...]
• Meta (19/38) Apr 05 2018 On the actual topic of the thread, the scrum master for this
• Bienlein (20/40) Apr 06 2018 Maybe one idea would be to get university people interested in D.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

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

rikki cattermole <rikki cattermole.co.nz> writes:

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.

Jack Stouffer <jack jackstouffer.com> writes:

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.

user1234 <user1234 12.nl> writes:

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.

Meta <jared771 gmail.com> writes:

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.

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Thu, Apr 05, 2018 at 09:42:50PM +0000, 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

Meta <jared771 gmail.com> writes:

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

Bienlein <jeti789 web.de> writes:

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 ... ;-).