incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maxime Beauchemin <>
Subject Challenges using Gitbox
Date Wed, 11 Apr 2018 18:11:54 GMT
Hi general@incubator!

This is an email discussing the challenges we are facing while using Github
/ Gitbox for our ASF project and wanted to start a thread to discuss
solutions and ways we can mitigate.

We're very grateful for Gitbox, but here are the challenges we're facing
with it:

1. Our PMs are not committers, so they can't do simple things as labeling
issues, closing issues and assigning issues to people. We need either for
them to have write access to Github, or for them to get some sort of
special committer status so they can get write access. Is voting PMs as
committers the solution here?

2. From what I gather using Github issues as a replacement for Jira is ok
as long as we set Github notifications to be sent to the mailing list. The
problem is that this makes our mailing list unusable for other purposes
than getting spammed out of our minds with Github notifications. I think
the solution would be to standardize on 2 mailing lists:
`github-notifications@{project}` and the good old `dev@`. Though
for early adopters `dev@` is probably busted as people have filters set up
against it already. So is the solution to create another list and get
everyone to sign up for it?

3. The mailing list is a bit dated. I'm saying "a bit" here as an attempt
to be polite. Maintainers have to sort through spam (AI had solved this a
decade ago!), it's hard to know how many people and who are signed up, no
weekly or daily digest-type features, SEO is bad and the list aren't very
searchable. Something like Google Groups would be a huge step forward here.

4. Github ecosystem services (build systems, code quality services, code
coverage services, version manager, ...) are hard and sometimes impossible
to setup (without admin Github privileges), forcing us to open INFRA Jira
tickets for this. I understand the limitations here, and a lot of it is on
the Github side, but would like to think of ways to mitigate this, perhaps
by using specified "main-forks" where committers have more control? Just a
list of "Apache Approved Github-services" would help.

The ASF is all about helping growing communities, and making committers as
productive as can be should be a top priority. Joining the ASF shouldn't
make governance harder.

I hear other software foundations are less opinionated in terms of tooling,
is that something the ASF should consider? What are the constraints?



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message