persistent byLine

[H. S. Teoh]

On Wed, Jul 24, 2013 at 08:17:08PM -0400, Jonathan M Davis wrote:
> On Wednesday, July 24, 2013 17:45:53 Nick Treleaven wrote:
> > Also is there any info on std.io? I assume it's still worthwhile to
> > update std.stdio docs and fix issues?
> 
> It is unknown when std.io will be ready for review, and the person
> working on it is quite busy. We certainly want to continue to fix
> issues in std.stdio.  What is more questionable is adding a lot of
> functionality to it. But bug fixes and the like should be fine, and
> I'm sure that some new functionality would be fine as well. We
> definitely don't want to make major changes to it though, since 
> we intend to replace it.
[...]

This makes me wonder if we should adopt a convention of using a public
fork/branch on GitHub when working on a new feature. That way, if the
person who started it can't work on it for whatever reason (too busy
IRL, working on other things, etc.), somebody else can step up and
continue the work, instead of the work being stalled without any
definite target completion time.

With GitHub, something like this is not only practical, but probably
also beneficial. For example, recently, I started working on a D port of
gdc's gdmd wrapper. After I got the initial functionality working, I got
busy with other stuff, but thanks to the code being available on github,
somebody else could step in and contribute pull requests. So development
continues in spite of me being unable to work on it at the moment.  And
sometimes, receiving pull requests on your branch is a big motivation
for you to get cracking on the code again. :)

For something as crucial as std.io (or other key Phobos components, in
general), I think this kind of approach is probably necessary. It
doesn't help our public image at all if people take a look at our
situation and say, "what's up with these D people, why is there only one
person working on key feature X and no progress is made because that
person is too busy". To improve our professionalism, this situation
ought to be improved.

Not to mention, like this also helps improve our bus factor when it
comes to key pieces of new functionality.


T

-- 
Spaghetti code may be tangly, but lasagna code is just cheesy.