That's my first message on this list, but I've been reading the messages for some months.
I'm interested in contributing to Apache Commons, but it was a little confusing to find where to help. Some of the issues in Jira are very old, but not solved. It's difficult for a newcomer like me to understand if that issue is not relevant (and maybe should have been discarded) or if it's only a matter of lack of someone to get it and have it done. Maybe using some labels, much like it's used in GH, like "help wanted", "bug", "enhancement" or even "good first issue". There is too much information and some of them are inconsistent. For example: https://issues.apache.org/jira/projects/CODEC/issues/CODEC-286 is open but https://github.com/apache/commons-codec/pull/40 is closed Maybe there should be a better integration between GH and Jira. Use GH Actions to change the Jira issue status on some events. There are also some issues that were closed and reopened, because there is no consensus on what should be done, like CODED-253 [open] (and CODEC-257 [closed]), about moving from Java 7 to 8. That's the kind of thing that scares newcomers. I'm even afraid that this message can be misinterpreted as somehow aggressive. That's not my intention, I only want to give you a view from outside. I've finally found that CODEC-285 is an issue that maybe I can help (Upgrade to JUnit v5.6.0). But there are already 4 PRs there. I'm not sure from where I should start: create a branch from the master or from some branch in those PRs? Starting from the master it's possible to have conflicts when merging all PRs. My plan is really to convert *all* tests in CODEC to Junit 5. Can I do it in a single massive PR or should I create a PR for each package? Should I step in on this issue? Can someone guide me in those small doubts I have? Regards, Itamar Carvalho On Mon, Feb 14, 2022 at 1:38 PM Gilles Sadowski <gillese...@gmail.com> wrote: > Le lun. 14 févr. 2022 à 16:11, Xeno Amess <xenoam...@gmail.com> a écrit : > > > > > Code not actively developed does not attract newcomers. > > Well I have to say the reason for "codes not actively developed" is a > > strong lack of alive committers, or more detailed, reviewers. > > In part, yes, but they are the consequence of each other (i.e. > a vicious circle). > > The main cause IMHO, is that we loose[1] the spirit of being > dedicated to a project/component. Contributions are "dropped" > as PR (usually) without follow-up (either here or on JIRA). > > > I have still 100+ unsolved prs in commons projects, some of which be 1 > or 2 > > years ago, but it seems there just are not enough reviewers, and pr lists > > in every repo grows longer and longer. > > That's the downside (in plain view?) of GH for a project that lacks > human resources (like "Commons") necessary for trimming the list > of PRs in a timely manner. > As you said in another comment, the PRs look like a stack; if there > is just one active committer, they rapidly become stale (because > "master" changes). Yet the OP quite often just lets them rot there. > A "dedicated" contributor should follow development, update the > PRs, collect them in JIRA, based on the type of issue that they fix. > IMHO, that work would establish a natural priority, speed up the > review (and become a measure of dedication[2]). > > > But on the other hand, free reviewers who have both ability and > willingness > > to review, well, are really lacking, it is the truth. > > [1] Largely "thanks" to GitHub IMO. > [2] Which the number of PRs cannot be by itself. > > > > > Gilles Sadowski <gillese...@gmail.com> 于2022年2月14日周一 22:34写道： > > > > > Le lun. 14 févr. 2022 à 14:34, Gary Gregory <garydgreg...@gmail.com> a > > > écrit : > > > > > > > > My guess is that this is a combination of the maturity of the > components > > > > > > The "maturity" rationale is not an explanation; it is a cause. > > > Code not actively developed does not attract newcomers. > > > It is not an "opinion" anymore; it is backed by the fact that > > > "Commons Math" API modernization had stalled on the basis > > > of that rationale; yet since the path has been unblocked, work > > > on [RNG], [Numbers], [Geometry], [Statistics] and [Math] itself > > > demonstrated how much room there was for improving[1] those > > > "mature" codes. > > > > > > Regards, > > > Gilles > > > > > > [1] Thanks to all who did it! > > > > > > > and people having moved on to jobs or hobbies that no longer requires > > > these > > > > components. > > > > > > > > Gary > > > > > > > >>> [...] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
