>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 <vabu.v...@gmail.com> 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 <schwa...@usta.de> 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 >> >> >