Re: [Groff] Overview, Sept. 2014

[Vaibhaw Pandey]

>With respect to Vaibhaw's candidacy as maintainer, I propose leaving
>the "looking for a new maintainer" notice on the webpage until the
>matter is definitively settled.  (If everyone's agreeable, I'll take
>ownership of the webpage.)

Yes, we should keep looking; to find Gotham the hero that it needs. :)

>Well, if he wants to contribute, he should simply do so.
>That means to find an area he is interested in (because he needs
>and uses it and has the skills to work on it, all of which are
>things only he can know), identify bugs or missing features
>in that area, write patches, and submit them.  Starting with
>something easy and with small patches, of course, then slowly
>increasing his range.

That is good advice Ingo. Thanks! It is my current focus.


On Wed, Sep 10, 2014 at 10:39 AM, Vaibhaw Pandey <address@hidden>
wrote:

> Wow! Don't we hate project management! :) Looks like the word "ETA" caused
> much heartburn.
> Let me explain what I meant when was talking offline with Peter.
>
> I hate processes as much as the next engineer but we do need some
> structure if we are to let more people in.
> I think, currently there is a lot of tribal knowledge in the group, which
> is great if we are sure that the group is permanent
> and wouldn't induct new members. & I believe nerds are much better at
> managing themselves than any "MBA" guys. :)
>
> Here's is what I wished to propose with some rationale:
>
> -1: A groff wiki which can contain:
> 0. A general list of team members with a general understanding of
> capabilities and responsibilities. Only so that it is discoverable by other
> people and we know whom to ask for assistance.
> 1. A list of major projects underway. Minor things should obviously, as
> Werner said, owned on the bug reports. This is where I mentioned ETAs. I
> didn't mean ETA in way of carved-in-rock time estimates but
> in the way of general complexity and current status of work. Just so that
> everyone knows what is the group up to in general. Peter summarized pretty
> well what is going on in the group currently. I simply wished
> that this information was available in general all the time as a sort of
> dashboard.
> 2. A list/diagram of all the modules/components in the groff ecosystem. It
> might link to any design documents we might have or create in the future.
>
> As I said, I didn't mean that we create processes to create roadblocks for
> a team that works well together, I thought this might help us communicate
> better and lower the barriers of entry for new people.
>
>
> Thanks,
> Vaibhaw
>
>
> On Wed, Sep 10, 2014 at 7:26 AM, Ingo Schwarze <address@hidden> wrote:
>
>> Hi Peter,
>>
>> Peter Schaffter wrote on Tue, Sep 09, 2014 at 05:31:38PM -0400:
>>
>> > The addition of useful new requests is part of our mission
>> > statement, and Doug's '.decor' fits the bill.  Problem is, the
>> > thread died, and nothing came of it.
>>
>> Well, even if a morsel fits the bill, there is no guarantee the
>> bird will be able to swallow it:  If i recall the discussion
>> correctly, there was broad agreement that getting underlining to
>> work correctly in filled text across line and page breaks is a
>> non-trivial endeavour.  So someone has to find the time to actually
>> look into it, design a concrete way to do it and prepare specific
>> patches, and send them around for review.
>>
>> > I suspect that's in part because we're all leery of mucking about
>> > in the sources.  It may also point to a dearth of skilled C++
>> > coders on the list, which, if true, is something we're going to
>> > have to address.
>>
>> The best way to address that would be for whoever is interested
>> to just do it and acquire the skills on the job.  No doubt C++
>> is a language with a steeper learning curve than, say, FORTRAN
>> or Python.  But look at the actual C++ we are talking about here.
>> There are neither templates nor rocket science in there.
>> Any average C programmer ought to be able to navigate that code
>> without getting lost.
>>
>> > On a similar note, Ulrich Lautner stepped forward to take on
>> > implementing a modified version of Knuth-Plass.  He produced a
>> > prototype showing that the application of dynamic programming to
>> > paragraph formatting can be done with a relatively small piece of
>> > code and at high speed.  I was excited, but interest from others
>> > hovered around zero.  I'm not sure why: from previous discussions,
>> > revamping groff's paragraph formatting is a priority.
>>
>> People had already expressed their opinions on the topic in general,
>> so there was no reason to restate all that.  If i recall correctly,
>> there weren't any specific patches against groff that anybody could
>> have reviewed.  There was at least one affirmative post in the style
>> of *OH, NICE!*, so there was little point in following up with a
>> classic ME2.  I, specifically, also didn't comment because i don't
>> feel competent with respect to that specific topic.
>>
>> > If Ulrich is to pursue this (provided he's still interested, and I,
>> > for one, sincerely hope he is), he needs assistance from the list.
>> > Off-list he wrote:
>> >
>> >  "I am not yet sure if I should try to integrate the code into groff.
>>
>> Well, if we want to get it done, then there is no other way than
>> to do exactly that.
>>
>> >   The groff code is not that readable, missing comments and common
>> >   coding conventions, such as
>> >     - using capitalization for class names
>> >     - special naming conventions for class members
>> >     - access to class members by setters / getters
>> >     - avoidance of global variables
>> >   So groff could benefit from some refactoring."
>> >
>> > He's probably right about refactoring,
>>
>> Well, there are two ways he can get up to speed:  Start with very
>> careful, very sparingly done refactoring in the area he wants to
>> work on, to make later integration easier and get to know the code
>> before changing functionality.  That can be combined with writing
>> unit tests if one feels so inclined, which is another desideratum.
>>
>> Or to accept the code base as is, start with integrating own code
>> adhering to the existing style, and get intimate with an area of
>> the code during that process, then proceed to refactoring when one
>> feels fully comfortable with the code base.
>>
>> Refactoring before or after adding functionality - either way has
>> its up- and downsides; some people may feel very strongly about it
>> from a methodology standpoint, but i consider that discussion moot
>> and the choice a matter of style, inclination, and the specific
>> situation and context.  Myself, i often enough oscillate between
>> refactoring, adding tests, and adding features, not doing either
>> in any clear phases, but doing all of it as part of one holistic
>> development process.
>>
>> The only thing you should usually refrain from is refactoring code
>> that requires no functional changes (there are exceptions, for
>> example when a security audit is urgently required).  And most
>> definitely, the worst thing one can do is advertise seemingly easy
>> refactoring across vast code bases as janitorial work to novices.
>> That will lead to nothing but the introduction of evil bugs, many
>> of which are almost guaranteed to remain undetected until much
>> later.
>>
>> > Vaibhaw Pandey stepped forward as a candidate for the role of
>> > maintainer, but he's discovering the job is bigger than he imagined.
>>
>> Well, if he wants to contribute, he should simply do so.
>> That means to find an area he is interested in (because he needs
>> and uses it and has the skills to work on it, all of which are
>> things only he can know), identify bugs or missing features
>> in that area, write patches, and submit them.  Starting with
>> something easy and with small patches, of course, then slowly
>> increasing his range.
>>
>> As long as one isn't a prolific contributor, it's kind of a moot
>> point talking about maintainership.
>>
>> > One of the issues he raised with me off-list is an apparent lack
>> > of organization.  It's true.
>>
>> I disagree.  Lack of reviewable patches is not lack of organization.
>> If you have reviewable patches and people go for each other's throat
>> instead of testing the patches and providing OKs or specific
>> suggestions for improvement, that might be called lack of
>> organization.  But that's not at all what we have.
>>
>> > Vaibhaw suggested that a list of major work that is ongoing in
>> > groff would be helpful, too, with some sort of ETA.
>> > I'm not sure such a list is even possible (esp. the ETAs),
>> > but it's a reasonable thing for any maintainer to want,
>>
>> That's not what a maintainer of a free software project would ask
>> of his fellow developers.  That's not even what a team leader would
>> ask of his workforce in a sweatshop.  It's what a Senior Vice
>> President of Technology would ask of his Managing Directors in a
>> corporation.  Not sure such a thing is that helpful with a handful
>> of part-time free software nerds.  ;-)
>>
>> In my experience, ETAs fail more often than not, even in a commercial
>> setting where everybody works full time, where that pesky thing
>> called real life doesn't intervene except when people fall ill, and
>> where even that is smoothened out by the law of large numbers.
>>
>> In my free software work, i have seen projects that everybody agreed
>> to regard as almost finished take three years to actually reach
>> production quality (most recent example: man.cgi) and i have seen
>> projects that everybody considered as almost impossible or at least
>> wildly out of scope to complete within two to eight weeks (notable
>> examples: mandoc .de support and man(1) integration).
>>
>> > very least, it might help us achieve a bit more focus.
>>
>> Or be more frustrated, because when you set up ETAs, you have reason
>> for dissatisfaction even if you *do* get cool stuff done (Imagine,
>> "pdfmom wasn't completed until almost half a year past ETA.  Let's
>> see, was that Deri's or Peter's fault?"  Like, what the hell?!?).
>>
>> I think a free project should focus on what people enjoy to do, and
>> enjoy to have achieved, not on what should get done, except, of
>> course, that you need to be able to distinguish useful additions
>> from useless or even distracting bloat, which is what your mission
>> statement already does quite nicely.
>>
>> Yours,
>>   Ingo
>>
>>
>