That's really cool. I saw the zookeeper had already joined the Hacktoberfest event(https://github.com/topics/hacktoberfest). You can login in (https://hacktoberfest.digitalocean.com/login) with your github account and enjoy yourself Note: you must register and make four valid pull requests (PRs) for projects which have a Hacktoberfest topic between October 1-31. Wish you can win that T-shirt :)
----- Original Message ----- From: Christopher <ctubb...@apache.org> To: dev@zookeeper.apache.org Subject: Re: hacktoberfest Date: 2020-10-08 05:03 On Wed, Oct 7, 2020 at 4:12 PM Enrico Olivelli <eolive...@gmail.com> wrote: > > Il Mer 7 Ott 2020, 21:02 Christopher <ctubb...@apache.org> ha scritto: > > > I created https://github.com/apache/zookeeper/pull/1489 > > (https://issues.apache.org/jira/browse/ZOOKEEPER-3962) > > > Thank you The sooner this gets updated, the sooner Hacktoberfest participants will get "credit" for the PRs they have created, and the easier it will be for new contributors to find ZK's repo. > > This should add the hacktoberfest label to the github repo. > > > > On a related note: I've noticed that a lot of people just do pull > > requests, but this project's committers are pretty strict about > > requiring a JIRA issue for everything, even trivial changes. That > > information is hard to find for new contributors. If you created a > > CONTRIBUTING.md file, GitHub would automatically provide a link to > > that for new contributors coming from GitHub. It would be easier to > > find than looking on the wiki/confluence page where that information > > is currently stored. (Alternatively, you could relax your constraints > > and not require a JIRA for everything... > > > We do not require a JIRA for very simple patches. But JIRA is super useful > in order to track release notes. So, I've seen some patches I thought were very simple, and a committer still commented on the PR asking them to create a JIRA, even though they could have just merged it as-is. I'm not really sure there's a clear demarcation point for users to know when something is considered "very simple" or not when the committers themselves aren't consistent on this. I think it's just confusing, and the requirement should go away entirely. If JIRA is useful to track some issues, sure, use it, but if somebody has already done the work, and it's self-contained in a PR, regardless of whether it's simple or not, I think just accepting it (if it's ready) is the most community-friendly thing to do, rather than ask a new contributor to create a JIRA at all (especially since they may not want to create a separate JIRA account, if they don't already have one). If a JIRA is really needed, the committer themselves can take on this responsibility instead of asking the contributor to do it... as a way of lowering the bar to contributing... especially if the user is a new contributor. If they are a regular contributor, then they should just be invited to be a committer. It's easier to hold committers to a higher standard of responsibility for these things. Personally, I don't find the generated JIRA "release notes" very useful. We used to use that in Accumulo, and we stopped doing it, because it was basically nothing more than a commit log. When the "release notes" are basically a replay of the git history, they lose their value. As a replacement, we started curating our release notes with the most important information users needed to know, and publishing that in a feed on our website alongside each release. We refer people (with a convenient link) to the full changes in the git history, if they are interested. Most of the git history does have references to issue numbers (because when we merge from the GitHub UI, it appends the PR number to the log message), if people want additional context from any conversation on the issue. I'm not suggesting ZK do this... it may not work for everybody. I'm merely describing how we did it in Accumulo and why, as an alternative perspective. > > Do you mind adding the CONTRIBUTING.md file into your PR? Just with a > simple link to confluence I'm not sure I want to do that with just a link to confluence. I don't think it's a good idea to make users click through multiple links to eventually get to the information. Personally, I think the information should be entirely contained in CONTRIBUTING.md and the confluence page should be decommissioned... and links to it should point to the CONTRIBUTING.md page in the repo instead. I'm not a fan of spreading documentation across multiple sites like that. I think everything should be on the project website or in the project repo. So, if I were to contribute a PR to update this, I would pursue it in that direction. Otherwise, I think somebody else should add CONTRIBUTING.md if they think it should be done differently. > > Enrico > > when Accumulo did this, it > > became much more friendly to new contributors.) > > > > On Wed, Oct 7, 2020 at 11:38 AM Enrico Olivelli <eolive...@gmail.com> > > wrote: > > > > > > Mate, > > > > > > Il giorno mer 7 ott 2020 alle ore 17:17 Szalay-Bekő Máté < > > > szalay.beko.m...@gmail.com> ha scritto: > > > > > > > Hello Devs! > > > > > > > > Are you participating in Hacktoberfest? What about tagging the > > > > ZooKeeper repo with the 'hacktoberfest' label to make it visible for > > > > Hacktoberfest automatically? > > > > > > > > > > This can be a very good idea. > > > IIUC if we open the project to that event we should take care of all of > > the > > > pull requests that will come, as we are doing with MuseDev/ApacheCon. > > > > > > So I would like to be sure that we have a least a couple of committers > > that > > > explicitly want to support the project and keep up with such pull > > requests. > > > > > > Enrico > > > > > > > > > > > > > > Currently I see more than 32.000 open-source repositories in this > > > > topic (https://github.com/topics/hacktoberfest), I think we should add > > > > ZooKeeper too. > > > > > > > > see: > > > > - https://hacktoberfest.digitalocean.com/hacktoberfest-update > > > > - > > > > > > https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/classifying-your-repository-with-topics > > > > > > > > BR, > > > > Mate > > > > > > > > p.s. I'm not sure who has the rights to assign our repo to this topic. > > > > (I don't have.) > > > > > >
