Hi, Adding my two cents to this thread. I would suggest that the Jira format imposes a high wall for newcomers. Since I have been trying to help with the project, I have to get familiar with Jira to be able to help with little changes. I cannot imagine how much more work others that are contributing constantly need to do just to keep the Jira format.
One thing that I find limiting with Jira is the ability to discuss an issue without it becoming a ticket. I know that for those cases you suggest to use the mailing list, but that becomes very cumbersome and non responsive. The conversation with people interested in the same language gets lost. And also, let's be honest, a mail doest have the same tools that you have in github to express your ideas. It becomes complicated to show code in a mail for people to discuss. That is where the "issues" section in github becomes a godsent. I would also suggest that we need other types of channels for communication. Fortunately this project has become very attractive to a wide community of data munchers but it is very hard for newcomers to get to know the project and to start contributing. It is difficult to find the right people to talk with in order to know where to help and start contributing. For this I would suggest having chats where informal conversations can happen. I read that your experience with slack wasn't the best, so I would suggest matrix.org since it is open source and decentralised. Btw, these chats should be language specific to avoid too much noise coming from all the contributions happening to the project. Another point that I think would benefit the whole arrow community is to have the projects in separate repositories, albeit in the same Apache github group. As I mentioned before, the project is super attractive and there should be an arrow implementation for all the languages under the sun. However, trying to keep them all under one location can be complicated for the administrators. They have to jump so many hoops just to get a language implementation to compile. The merges to the repo become harder than they should be. As long as all the implementations follow the arrow specification and comply with all the required tests, is it necessary for them to be in the same repo? Btw, have a look at the Ballista project. it isnt limited by these constraints, allowing it to move faster and capture more contributors. Sorry for the large mail but I had to take it out of my chest. Thanks, Fernando On Tue, Mar 2, 2021 at 9:26 AM Antoine Pitrou <anto...@python.org> wrote: > > Hi Jorge, > > On Tue, 2 Mar 2021 08:55:03 +0100 > Jorge Cardoso Leitão <jorgecarlei...@gmail.com> wrote: > > Hi, > > > > FWIW, the amount of bureaucracy that goes into JIRA is a major > contributing > > factor for the reduction of my time commitment to this project by 80%+. > > Can you expand a bit on this? In particular, which aspects of using > JIRA feel bureaucratic? Is it the requirement to create a new issue > for each PR? Or is it other concerns (such as the UI for entering or > searching issues)? > > I can't say I like JIRA myself, but at least it provides the > classification and navigation features that I would expect from an > issue tracker. The Github issue tracker AFAIK is rudimentary and not > really practical when a project has accumulated many issues (but they > may have changed this recently). > > > The major challenge is that most discussions happen where PRs are created > > and seen, which is on github, but JIRA and mailing list is used for other > > types of decisions. In this model, how do we preserve curated information > > about the decision process while at the same time leverage both JIRA and > > github's capabilities? > > In my experience, discussion on JIRA is about the issue itself (for > example diagnosing a bug or discussing a feature), then discussion on > the PR is about the implementation. JIRA discussions are generally > readable by users (and indeed, users often participate) while PR > discussions are really for developers of the project. > > > OTOH, asking contributors to create a jira account > > and committers to add the person as contributor, as well as the email > spam > > and the merge process is a large barrier. > > FWIW, I've set up a mail filter that sends all "work logged" automated > mail to the trashbin. I agree it's unfortunate that developers have to > do that. I also have other qualms with the Apache JIRA configuration, > such as the fact that "labels" (keywords) are shared between all > projects, so there is essentially a million of them with no effort at > taxonomy. > > > IMO the foundation could be clearer wrt to what does it mean with > > information being preserved and available (e.g. on apache servers?) and > if > > yes, follow it through by hosting all their projects on their own github > / > > gitlab / whatever, where issues and PRs are on the same platform, and > offer > > SSO for contributors as a way to prove identity across the system. But > that > > is also a complex operation with a lot of unknowns... > > From what I see of the ASF's velocity, I wouldn't expect such a large > breakthrough in the short future. > > (this is not trying to badmouth the ASF, just a pragmatic evaluation) > > Regards > > Antoine. > > >
