Hello. Le ven. 24 juil. 2020 à 17:45, Stefan Bodewig <bode...@apache.org> a écrit : > > This is an attempt at answering something raised be Gilles in a > different thread. I'm afraid it is getting longer than I > intended. Something seems to need to get out. Sorry. > > On 2020-07-23, Gilles Sadowski wrote: > > > I missed the turn where this project's PMC decided that we must > > be present on GH in order to continue what some of us have been > > doing for more than 10 years. > > The project decided to set up github mirrors and with the exposure to > github you get the rest of the package.
Depends on what "get" means. The mirror functionality does not necessarily entail the "rest". For just one example, see [1]. Thus, to mimic Xeno's wording (up to a point): 0. Post a proposal to "dev@". 1. Create a JIRA issue. 2. Create GH PR that will be linked from JIRA. 3. Ask for comment in JIRA. 4. Get review, as JIRA comments (until convergence/compliance). 5. ["none of contributor's business"] Merge. > I don't remember whether we had an explicit vote about enabling github > mirrors, much less whether it has been a component by component > decision. If I'm not mistaken, mirrors come by default with any new git repository. A mirror gives more exposure to the project, which is indeed good, as you say below. > Putting aside what I think about github as a company Why? One should learn from history that this company is accustomed to "gifts" whose cost can (will) appear much later on. > one thing that I > have observed with projects migrating to github across the board is it > seems to lower the barrier for new contributors. And this is good, as said above, but up to a point as you indeed note: > This results in two > things: (1) you get more contributions and (2) the contributors usually > don't stick around, most contributions are drive-by one-off > contributions. > > Gilles, I believe you have seen an uptick in contributions to the > sevaral maths components even if you don't like they way they have > happened. The following might sound dismissive but it is not: We appreciate anyone interested in helping out. However the point is indeed "helping out": If it takes much more time to review/correct/merge a contribution than make it myself, this is not helping out, quite the contrary. Of course, there is a learning curve for a new contributor; I have, every time, spelled out in (fairly) full what was expected but (my impression is the same as yours) for a one-off contribution, it is out of proportion. > > There is a trend to make GH central to the development process > > (marginalizing "dev@" and JIRA and colonizing "issues@"). > > This is troubling me as well. Where "this" is that using github PRs > seems to keep the potential future committers away from the dev list and > they never become part of a component's community. IMO, GitHub's motto could be "Code over community". It's not necessarily bad, but GitHub is understandably (and obviously primarily) interested in *its* community. > We do get more contributions anf the quality of the codebases likely > improves because of this, but I feel it makes the community weaker. There is experimental data that there's no causality link between using GitHub as a mirror and this community's way(s) of working for at least 10 years: * Matt has undertaken the overhaul of [Geometry] codes, without having write access to the Apache repository (cf. [1] for just one example), * ditto, earlier, with the polishing, up to the last percent of coverage, (and more!) of [RNG] by Alex. > Discussions only rarely happen "here" nowadays. Whereas, in the not-so-distant past, this was severely frowned upon. Whether using GitHub almost exclusively (bypassing the "dev" ML and JIRA) is progress or not, it was not approved, but this PMC let it happen. > There are a few people like Gary, Rob and a few others who manage to > devote time across almost all components and I adore them for that. And > we need them because most of the components wouldn't stand a chance to > get a release vote through without them. Those who do the work get to decide. No arguing against that. Being more productive (by necessity) with GitHub, increases the bias, which you noted, of attracting more and more contributors who attempt to get their code merged by, so to speak, "trial and error" (as opposed to "internalize" requirements). > Our component communities have > become too small to sustain themselves and at the same time some of them > see more commits than they used to have in "the good old days" with many > people active on this list. Xeno has a point in saying that this problem did not appear with GitHub. I've raised it myself several times over the years, but the readers here have always remained unfazed. > I haven't got an answer to this. Neither have I, at least not an effective one. Last year, I proposed that we participate in GSoC. By "we", I thought I was meaning "Commons", but only the math-related components provided mentors, and the tasks proved too complicated for newcomers. :-( We recently got mail about the "Outreachy" program. Not a blink from the PMC. > [Sidenote: In the early 90s I contributed to my first open source > project before CVS had a network protocol. I can not understand why > having to checkout a SCM repository, creating a patch and sending it to > somebody else is a burden that keeps people from contributing. Perhaps there is a wrong perception of a technical burden; but the [Geometry] example demonstrates that there is zero additional burden. > I have > learnt to accept this as a fact. There are lots of facts I cannot > explain. I would bet that marketing power can explain a lot of those facts. > And yes, I know I sound old. I am :-)] Old (?) and... wise! ;-) Gilles [1] https://issues.apache.org/jira/projects/GEOMETRY/issues/GEOMETRY-95 > Stefan > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
