Re: Challenges using Gitbox

2020-08-18 Thread Dave Fisher
The correct list is either here. 

(1) Have a look at the Incubator website and we can discuss a patch to our 
guidance. 

Or

(2) d...@community.apache.org

Like Ted I gained my first committership by answering user questions in a 
project. IPMC membership by migrating websites, Infra for a podling. Apache 
Membership by mentoring.

When I started with Apache I was managing a developer who was working at my 
direction. They got status well before me.

One can certainly vote on releases without coding. Being able to evaluate and 
vote on releases is something every PMC needs.

Regards,
Dave

Sent from my iPhone

> On Aug 18, 2020, at 8:04 PM, Maxime Beauchemin  
> wrote:
> 
> How can I propose this as a change? What's the proper forum / mailing list?
> 
>> On Tue, Apr 17, 2018, 9:49 AM Ted Dunning  wrote:
>> 
>> On Mon, Apr 16, 2018 at 8:28 PM, Ralph Goers 
>> wrote:
>> 
>>> ...
> such people can earn merit by becoming involved with the community and
 helping out where they can.
 
 In theory, that sounds good, but as a practical matter, how many people
 that have ever been on the ASF board of directors neither know/knew,
>> nor
 use(d) any programming languages in getting there? IOW, they got there
 exclusively on their ability to write documentation, do community
 relations, or utilize other non-coding skills?
>>> 
>>> It has happened many times. When I was a committer on Apache Cocoon we
>>> voted Arje Cahn as a committer for his contributions to the project which
>>> had nothing to do with coding. He was voted in as an ASF member for
>> pretty
>>> much the same reason.
>>> 
>> 
>> 
>> It has happened. I was voted as a committer for simply answering questions
>> (and it stuck). I know of at least one or two others.
>> 
>> But we should be honest here. It isn't all that common. It should be much
>> more common.
>> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



Re: Challenges using Gitbox

2020-08-18 Thread Maxime Beauchemin
How can I propose this as a change? What's the proper forum / mailing list?

On Tue, Apr 17, 2018, 9:49 AM Ted Dunning  wrote:

> On Mon, Apr 16, 2018 at 8:28 PM, Ralph Goers 
> wrote:
>
> > ...
> > >> such people can earn merit by becoming involved with the community and
> > > helping out where they can.
> > >
> > > In theory, that sounds good, but as a practical matter, how many people
> > > that have ever been on the ASF board of directors neither know/knew,
> nor
> > > use(d) any programming languages in getting there? IOW, they got there
> > > exclusively on their ability to write documentation, do community
> > > relations, or utilize other non-coding skills?
> >
> > It has happened many times. When I was a committer on Apache Cocoon we
> > voted Arje Cahn as a committer for his contributions to the project which
> > had nothing to do with coding. He was voted in as an ASF member for
> pretty
> > much the same reason.
> >
>
>
> It has happened. I was voted as a committer for simply answering questions
> (and it stuck). I know of at least one or two others.
>
> But we should be honest here. It isn't all that common. It should be much
> more common.
>


Re: Challenges using Gitbox

2018-04-17 Thread Ted Dunning
On Mon, Apr 16, 2018 at 8:28 PM, Ralph Goers 
wrote:

> ...
> >> such people can earn merit by becoming involved with the community and
> > helping out where they can.
> >
> > In theory, that sounds good, but as a practical matter, how many people
> > that have ever been on the ASF board of directors neither know/knew, nor
> > use(d) any programming languages in getting there? IOW, they got there
> > exclusively on their ability to write documentation, do community
> > relations, or utilize other non-coding skills?
>
> It has happened many times. When I was a committer on Apache Cocoon we
> voted Arje Cahn as a committer for his contributions to the project which
> had nothing to do with coding. He was voted in as an ASF member for pretty
> much the same reason.
>


It has happened. I was voted as a committer for simply answering questions
(and it stuck). I know of at least one or two others.

But we should be honest here. It isn't all that common. It should be much
more common.


Re: Challenges using Gitbox

2018-04-16 Thread Ralph Goers


> On Apr 16, 2018, at 4:22 PM, toki  wrote:
> 
> On 04/16/2018 07:37 PM, Ralph Goers wrote:
>> IMO, it is inappropriate to add project managers to a project as a committer 
>> just because they are employed by a company that has committers who are paid 
>> to work on the project.
> 
> There are some companies who have a person whose sole duty is manage the
> employees that work on a specific open source project.
> 
> As such, open source projects have two options:
> * grant the employee position the access needed to manage the project,
> so that everybody can see what is going on;
> * deny the employ position the needed access, and be surprised by what
> the company contributes. In most instances, the surprises are things
> that were neither anticipated, nor considered needed by the non-employee
> contributors;

The implication with the way this is all being stated is that the project 
manager is making the decisions about everything and everyone is marching to 
his orders. That is just not how the ASF is supposed to operate.  It is the 
PMC’s job, as a group of collaborators, to make these decisions. That said, 
there is no reason the PMC can’t allow project managers (or anyone else) to 
make proposals regarding a roadmap using Confluence, so long as they are 
discussed and approved by the PMC. The project manager is then free to create 
Jira issues that align with the roadmap. However, what if a committer who 
doesn’t work for the same company as the project manager wants to implement one 
of the roadmap features and/or has different ideas about how it should be done? 
It is up to the PMC as a whole to resolve that, not any one individual.

What you are missing above is the third option. Grant them access to Jira and 
Confluence. Then have them discuss what they are doing on the mailing list. The 
basic difference here is that the individual is not “running” the project but 
is instead contributing to it. If,  after the merit is earned, the PMC decides 
to grant commit rights and/or make them a PMC member, then great. That is how 
it is supposed to work.

The point of all this is, the ASF isn’t trying to get in the way of anyone 
doing their job. Instead, it is trying to put each individual on an equal 
footing with everyone else. Sometimes this may get in the way of a company’s 
goals, but if they wanted to keep total control of the project then they 
shouldn’t have contributed it to the ASF.

>> 
> 
> Do you really want to see a build of, say, Apache OpenOffice, with
> complete L10N (Help documentation, UI, grammar checking, spell checking
> for both ancient, medieval, and modern forms of the official
> language(s), and writing system(s), etc.) for say, Crimea, North Korea,
> or Syria, with no prior notice, much less discussion. I have a pretty
> good idea of what ASF-Legal will say about that specific scenario.
> 
> Sure the company can just fork the project. It has happened before, and
> it will happen again. But setting up conditions where forking is the
> only option for a community based project is, IMNSHO, non-viable.
> 
>> such people can earn merit by becoming involved with the community and
> helping out where they can.
> 
> In theory, that sounds good, but as a practical matter, how many people
> that have ever been on the ASF board of directors neither know/knew, nor
> use(d) any programming languages in getting there? IOW, they got there
> exclusively on their ability to write documentation, do community
> relations, or utilize other non-coding skills?

It has happened many times. When I was a committer on Apache Cocoon we voted 
Arje Cahn as a committer for his contributions to the project which had nothing 
to do with coding. He was voted in as an ASF member for pretty much the same 
reason.

Ralph



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



Re: Challenges using Gitbox

2018-04-16 Thread Greg Stein
On Mon, Apr 16, 2018 at 6:22 PM, toki  wrote:
>...

> In theory, that sounds good, but as a practical matter, how many people
> that have ever been on the ASF board of directors neither know/knew, nor
> use(d) any programming languages in getting there? IOW, they got there
> exclusively on their ability to write documentation, do community
> relations, or utilize other non-coding skills?
>

Rich Bowen. Current Director of the Foundation, third term, I believe.

He earned his merit through years of working on documentation for the
Apache HTTP Server Project, and through just as many years helping to
organize our conferences.

Cheers,
-g


Re: Challenges using Gitbox

2018-04-16 Thread Dave Fisher
Hi -

Having started on a project as such a “Management" person ….

> On Apr 16, 2018, at 4:22 PM, toki  wrote:
> 
> On 04/16/2018 07:37 PM, Ralph Goers wrote:
>> IMO, it is inappropriate to add project managers to a project as a committer 
>> just because they are employed by a company that has committers who are paid 
>> to work on the project.
> 
> There are some companies who have a person whose sole duty is manage the
> employees that work on a specific open source project.
> 
> As such, open source projects have two options:
> * grant the employee position the access needed to manage the project,
> so that everybody can see what is going on;
> * deny the employ position the needed access, and be surprised by what
> the company contributes. In most instances, the surprises are things
> that were neither anticipated, nor considered needed by the non-employee
> contributors;
> 
> How fast could an individual expect to be given the authority to do this
> type of project management, without contributing a line of code?

It depends on the project. The place to start is by contributing to discussions 
on the dev@ and/or user@ lists in order to get recognized. If there are 
developers from $DayJob on the PPMC they with the rest of the PPMC can 
determine when they get these people involved with rights.

Apache projects require a flat, meritocracy and these PM need to earn the right 
within the Project. That right then is theirs whether or not they remain 
employed by $BigCo.

If having commit rights on GitHub is a problem then the project can use a Wiki 
(MoinMoin or Confluence) and/or an Issue Tracker (JIRA or Bugzilla).

The project should not be surprised as the developers should be communicating 
about what they are developing.

This is Open Source Development … do it in public and be happily surprised when 
unexpected people show up with contributions. Grow a true community.

Regards,
Dave

> 
> Ralph wrote:
> 
>> Companies do not do the prioritization, planning, road-mapping,
> shaping product-design, etc of ASF projects. The committers and PMC
> members do that.
> 
> Most of the companies that have a person whose sole duty is to manage
> employees that work on a specific open source project, will ignore
> upstream requests, if they don't have access to do management things
> there. This will result in undesirable surprises.
> 
> If the company PM does have access at the Open Source Project level,
> then the input from the other contributors will be taken into consideration.
> 
> Yes, there is a very fine line to walk, between allowing a company
> position authority to do "x", and preventing the company from taking
> over the project.
> 
>> They can use their own Jira repo for that kind of stuff.
> 
> Do you really want to see a build of, say, Apache OpenOffice, with
> complete L10N (Help documentation, UI, grammar checking, spell checking
> for both ancient, medieval, and modern forms of the official
> language(s), and writing system(s), etc.) for say, Crimea, North Korea,
> or Syria, with no prior notice, much less discussion. I have a pretty
> good idea of what ASF-Legal will say about that specific scenario.
> 
> Sure the company can just fork the project. It has happened before, and
> it will happen again. But setting up conditions where forking is the
> only option for a community based project is, IMNSHO, non-viable.
> 
>> such people can earn merit by becoming involved with the community and
> helping out where they can.
> 
> In theory, that sounds good, but as a practical matter, how many people
> that have ever been on the ASF board of directors neither know/knew, nor
> use(d) any programming languages in getting there? IOW, they got there
> exclusively on their ability to write documentation, do community
> relations, or utilize other non-coding skills?
> 
> jonathon
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 



signature.asc
Description: Message signed with OpenPGP


Re: Challenges using Gitbox

2018-04-16 Thread toki
On 04/16/2018 07:37 PM, Ralph Goers wrote:
> IMO, it is inappropriate to add project managers to a project as a committer 
> just because they are employed by a company that has committers who are paid 
> to work on the project.

There are some companies who have a person whose sole duty is manage the
employees that work on a specific open source project.

As such, open source projects have two options:
* grant the employee position the access needed to manage the project,
so that everybody can see what is going on;
* deny the employ position the needed access, and be surprised by what
the company contributes. In most instances, the surprises are things
that were neither anticipated, nor considered needed by the non-employee
contributors;

How fast could an individual expect to be given the authority to do this
type of project management, without contributing a line of code?

Ralph wrote:

> Companies do not do the prioritization, planning, road-mapping,
shaping product-design, etc of ASF projects. The committers and PMC
members do that.

Most of the companies that have a person whose sole duty is to manage
employees that work on a specific open source project, will ignore
upstream requests, if they don't have access to do management things
there. This will result in undesirable surprises.

If the company PM does have access at the Open Source Project level,
then the input from the other contributors will be taken into consideration.

Yes, there is a very fine line to walk, between allowing a company
position authority to do "x", and preventing the company from taking
over the project.

> They can use their own Jira repo for that kind of stuff. 

Do you really want to see a build of, say, Apache OpenOffice, with
complete L10N (Help documentation, UI, grammar checking, spell checking
for both ancient, medieval, and modern forms of the official
language(s), and writing system(s), etc.) for say, Crimea, North Korea,
or Syria, with no prior notice, much less discussion. I have a pretty
good idea of what ASF-Legal will say about that specific scenario.

Sure the company can just fork the project. It has happened before, and
it will happen again. But setting up conditions where forking is the
only option for a community based project is, IMNSHO, non-viable.

> such people can earn merit by becoming involved with the community and
helping out where they can.

In theory, that sounds good, but as a practical matter, how many people
that have ever been on the ASF board of directors neither know/knew, nor
use(d) any programming languages in getting there? IOW, they got there
exclusively on their ability to write documentation, do community
relations, or utilize other non-coding skills?

jonathon

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



Re: Challenges using Gitbox

2018-04-16 Thread Dave Fisher

> On Apr 16, 2018, at 1:52 PM, Ted Dunning  wrote:
> 
> On Mon, Apr 16, 2018 at 12:37 PM, Ralph Goers 
> wrote:
> 
>> 
>> 
>>> On Apr 16, 2018, at 10:46 AM, Maxime Beauchemin <
>> maximebeauche...@gmail.com> wrote:
>>> 
>>> About PMs, or other "non-coding contributors", it's pretty common to have
>>> them at sponsoring organizations. For example both Airbnb and Lyft both
>>> have a dedicated PM for Apache Superset. While they don't write code,
>> they
>>> contribute to the project and many other ways (prioritization / planning
>> /
>>> road-mapping, shaping product design, communication, training,
>>> documentation, bug reports, issue triaging,  organizing events, ...). It
>>> sounds like the solution is to make them committers to provide them with
>>> the level of control they need on Github.
>> 
>> I have a problem with the way this is phrased. Companies do not do the
>> prioritization, planning, road-mapping, shaping product-design, etc of ASF
>> projects. The committers and PMC members do that.
> 
> 
> 
> The phrasing is problematic, clearly.
> 
> But managers at companies *do* have an outsized influence because they can
> divert a substantial amount of people-power to particular issues. As such,
> the priority setting, road mapping and triaging that they are doing is done
> to keep the corporation's efforts coherent. Keeping these efforts coherent
> is actually a community service, as I see it. Doing these efforts off-list
> is a disservice, however, and is a common anti-pattern in communities.
> 
> Overall, I think that it is great if somebody takes a strong and public
> position to help organize efforts of the community and I think that efforts
> like that should be recognized. At the same time, I am strenuously of the
> opinion that doing the same thing off-list is something that should not be
> recognized.
> 
> The difference is probably not clear to most corporate overlords.

Here is the main documentation. [0]
Here is a short discussion. [1]
Here is a very long one [2]

Please have a look. (Wondering lately if we need a page for Corporations about 
how to Incubate a Project.)

Regards,
Dave

[0] https://www.apache.org/foundation/how-it-works.html#management 

[1] https://community.apache.org/committers/decisionMaking.html 

[2] 
https://blogs.apache.org/foundation/entry/success-at-apache-asynchronous-decision
 







signature.asc
Description: Message signed with OpenPGP


Re: Challenges using Gitbox

2018-04-16 Thread Ted Dunning
On Mon, Apr 16, 2018 at 12:37 PM, Ralph Goers 
wrote:

>
>
> > On Apr 16, 2018, at 10:46 AM, Maxime Beauchemin <
> maximebeauche...@gmail.com> wrote:
> >
> > About PMs, or other "non-coding contributors", it's pretty common to have
> > them at sponsoring organizations. For example both Airbnb and Lyft both
> > have a dedicated PM for Apache Superset. While they don't write code,
> they
> > contribute to the project and many other ways (prioritization / planning
> /
> > road-mapping, shaping product design, communication, training,
> > documentation, bug reports, issue triaging,  organizing events, ...). It
> > sounds like the solution is to make them committers to provide them with
> > the level of control they need on Github.
>
> I have a problem with the way this is phrased. Companies do not do the
> prioritization, planning, road-mapping, shaping product-design, etc of ASF
> projects. The committers and PMC members do that.



The phrasing is problematic, clearly.

But managers at companies *do* have an outsized influence because they can
divert a substantial amount of people-power to particular issues. As such,
the priority setting, road mapping and triaging that they are doing is done
to keep the corporation's efforts coherent. Keeping these efforts coherent
is actually a community service, as I see it. Doing these efforts off-list
is a disservice, however, and is a common anti-pattern in communities.

Overall, I think that it is great if somebody takes a strong and public
position to help organize efforts of the community and I think that efforts
like that should be recognized. At the same time, I am strenuously of the
opinion that doing the same thing off-list is something that should not be
recognized.

The difference is probably not clear to most corporate overlords.


Re: Challenges using Gitbox

2018-04-16 Thread Ralph Goers


> On Apr 16, 2018, at 10:46 AM, Maxime Beauchemin  
> wrote:
> 
> About PMs, or other "non-coding contributors", it's pretty common to have
> them at sponsoring organizations. For example both Airbnb and Lyft both
> have a dedicated PM for Apache Superset. While they don't write code, they
> contribute to the project and many other ways (prioritization / planning /
> road-mapping, shaping product design, communication, training,
> documentation, bug reports, issue triaging,  organizing events, ...). It
> sounds like the solution is to make them committers to provide them with
> the level of control they need on Github.

I have a problem with the way this is phrased. Companies do not do the 
prioritization, planning, road-mapping, shaping product-design, etc of ASF 
projects. The committers and PMC members do that. IMO, it is inappropriate to 
add project managers to a project as a committer just because they are employed 
by a company that has committers who are paid to work on the project. They can 
use their own Jira repo for that kind of stuff. Furthermore, merit should be 
earned, not just handed out to anyone who needs it to do the job their employer 
requires.

That said, such people can earn merit by becoming involved with the community 
and helping out where they can.

Ralph



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



Re: Challenges using Gitbox

2018-04-16 Thread Dave Fisher

Hi -

> Another point I didn't bring up in my original email is the obsolescence of
> Apache's svn binaries repository in the light of commonly used package
> manager (Pypi.org for Python, npm for Javacsript, ..., Maven for Java(?) ,
> ...). While I understand the importance of the ASF being independent and
> the need for signed binaries, it seems like effectively everyone will just
> use the release available on popular package manager. Maybe in a perfect
> world we'd have tooling that pushes to both repos atomically. In the
> meantime, I guess it's for podlings to build their own process & tooling to
> ship their releases.

Every project must put all of their Apache releases onto the Apache Infra and 
offer the source download. This is Open Source! The binaries are convenience. 
Most projects treat these the same, and many use other channels to provide 
binaries.

Maven releases are supported though repository.apache.org 
 and can be pushed through to Maven Central.
I know of at least one project that is pushing out through NPM. That would be 
Apache Royale.
Apache OpenOffice binaries are too much for the Apache Mirror system and the 
PMC uses SourceForge.

Ask around about binaries.

If you have questions about the release policy then ask on legal-discuss@

Regards,
Dave

> 
> On Mon, Apr 16, 2018 at 6:39 AM, Ralph Goers 
> wrote:
> 
>> 
>> 
>>> On Apr 11, 2018, at 11:11 AM, Maxime Beauchemin <
>> maximebeauche...@gmail.com> wrote:
>>> 
>>> 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?
>> 
>> 
>> I’m just wondering what a project manager is in the context of an Apache
>> project? Why would anyone be assigning issues to people? This is a
>> volunteer organization.  If this is being done as part of an employer then
>> it should not be handled at the ASF.
>> 
>> Ralph
>> 
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>> 
>> 



signature.asc
Description: Message signed with OpenPGP


Re: Challenges using Gitbox

2018-04-16 Thread Maxime Beauchemin
Thanks everyone for all the input!

I had not looked at https://lists.apache.org/ in a while and it looks
pretty usable along with the "site:" Google trick. Thanks to those who made
"Apache Mail Archives" happen!

About PMs, or other "non-coding contributors", it's pretty common to have
them at sponsoring organizations. For example both Airbnb and Lyft both
have a dedicated PM for Apache Superset. While they don't write code, they
contribute to the project and many other ways (prioritization / planning /
road-mapping, shaping product design, communication, training,
documentation, bug reports, issue triaging,  organizing events, ...). It
sounds like the solution is to make them committers to provide them with
the level of control they need on Github.

Another point I didn't bring up in my original email is the obsolescence of
Apache's svn binaries repository in the light of commonly used package
manager (Pypi.org for Python, npm for Javacsript, ..., Maven for Java(?) ,
...). While I understand the importance of the ASF being independent and
the need for signed binaries, it seems like effectively everyone will just
use the release available on popular package manager. Maybe in a perfect
world we'd have tooling that pushes to both repos atomically. In the
meantime, I guess it's for podlings to build their own process & tooling to
ship their releases.

On Mon, Apr 16, 2018 at 6:39 AM, Ralph Goers 
wrote:

>
>
> > On Apr 11, 2018, at 11:11 AM, Maxime Beauchemin <
> maximebeauche...@gmail.com> wrote:
> >
> > 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?
>
>
> I’m just wondering what a project manager is in the context of an Apache
> project? Why would anyone be assigning issues to people? This is a
> volunteer organization.  If this is being done as part of an employer then
> it should not be handled at the ASF.
>
> Ralph
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


Re: Challenges using Gitbox

2018-04-16 Thread Ralph Goers


> On Apr 11, 2018, at 11:11 AM, Maxime Beauchemin  
> wrote:
> 
> 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?


I’m just wondering what a project manager is in the context of an Apache 
project? Why would anyone be assigning issues to people? This is a volunteer 
organization.  If this is being done as part of an employer then it should not 
be handled at the ASF.

Ralph

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



Re: Challenges using Gitbox

2018-04-11 Thread Daniel Gruno

On 04/11/2018 09:58 PM, Ted Dunning wrote:




3. The mailing list is a bit dated.



Totally true.  Pony helps a bit: https://lists.apache.org/

But not all that much.

Spam shouldn't be much of a problem (it isn't on other lists that I have
been part of). Aside from self-inflicted spam like notifications, that is.

SE is definitely poor. Pony makes the list more searchable, but not as well
as a Google thing.



I think this is a matter of newness and prominence, not as much whether 
the pony is good or bad. I can easily google stuff on there if I search 
for "site:lists.apache.org fosdem 2018" and read up on fosdem topics 
(Google knows how to crawl it)...but there are some 20 million emails to 
index on a relatively new sub domain, and that's probably gonna take a 
while. It will very likely change and be easier in the future, but I've 
no idea how fast that'll happen.


Anyway, as we always say, patches welcome :). If people have improvement 
suggestions, we'll gladly accept them at the pony mail project. There 
are several major overhauls on the drawing board, but with many users 
and very few contributors, this moves along quite slowly.


With regards,
Daniel.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



Re: Challenges using Gitbox

2018-04-11 Thread Ted Dunning
On Wed, Apr 11, 2018 at 11:11 AM, Maxime Beauchemin <
maximebeauche...@gmail.com> wrote:

> 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?
>

Why not make them committers?

Seriously. It sounds like the project needs and wants them to do stuff that
requires committer-fu. What possible reason is there not to give it to them?


> 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}.apache.org` 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?
>

Can't you tone down the notifications to dev@ and arrange for all
notifications to be sent to notifications@?

I am asking because I don't know if it is possible.


> 3. The mailing list is a bit dated.


Totally true.  Pony helps a bit: https://lists.apache.org/

But not all that much.

Spam shouldn't be much of a problem (it isn't on other lists that I have
been part of). Aside from self-inflicted spam like notifications, that is.

SE is definitely poor. Pony makes the list more searchable, but not as well
as a Google thing.



> 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.
>

Ask infra. My experience is that this stabilizes pretty quickly with
limited requests after a break-in period.

That means that the current infra-centric arrangement is painful a bit at
first, but it declines in prominence pretty quickly.



> 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.
>

Well actually ASF is, in many ways, all about certain downstream
consumers of software and, in particular, about certain governance
guarantees. The support of communities is a derived goal because the
downstream is best served by having robust communities.

As such, joining ASF is *absolutely* going to make some aspects of
governance considerably harder.

That said, the tooling shouldn't be vastly harder.

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


The core constraints are (roughly, probably not quite complete):

1) downstream consumers of source code releases have comfort around
dependency risks and licensing

2) Apache has "good enough" provenance on essentially every line of code.

3) Apache is open and historically transparent with respect to decision
making. Open across time zones and presence.

4) Failures or adverse takeovers of non-Apache entities will not compromise
the mission of Apache

5) Apache doesn't run with professional fundraisers out beating the bushes
(this isn't really an axiom as much as a consequence)

6) Contributors, committers and members are all individuals and participate
as such. This is in contrast to foundations where corporations are members.
It also relates to the fact that Apache is a charity rather than a trade
organization.

Item (1) is where the licensing limitations and signing and release
policies come from.

Item (2) was one of the major sticking points with github because it was
hard to understand how much confidence we could have about who checked in
code.

Item (3) is where the mailing list rules and voting practices come from.

Item (4) is where the reticence about using external services for mailing
lists and ticketing comes from.

Item (5) limits the bandwidth and special purpose tooling that any single
project can expect to have created and maintained.

Item (6) is why a company has trouble getting 

Re: Challenges using Gitbox

2018-04-11 Thread Dave Fisher
Hi -


> On Apr 11, 2018, at 11:11 AM, Maxime Beauchemin  
> wrote:
> 
> 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?

Yes - make people committers to have access. People will do the correct thing 
and work in their area. If someone doesn’t then it is an SCM and the changes 
can be reverted.

> 
> 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}.apache.org` 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?

Projects typically have a commits@ or issues@ ML and you can redirect there. 
Your PPMC members should follow that list.

The dev@ list is critical for recording decisions.

> 
> 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.

Have a look at lists.apache.org  which is a 
searchable archive of every Apache Mailing list.

The lists are permanent records of the ASF and the Foundation has to maintain 
these. Relying on third parties is not within policy.

> 
> 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 Kira
> 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.

You should have a discussion with Infra about what privileges you are missing 
and if it is possible for these to be enabled through GitBox. Perhaps the 
distinction could be made between Committer and PPMC member within the LDAP, 
but I really don’t know.

> 
> 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.

At a minimum the ASF requires that the Apache License is used and that 
everything is compliant. This can be difficult. We also have minimal rules for 
how Releases are done to our shared and consistent Infrastructure. Once 
released the software is held by the Foundation for the public good in 
perpetuity.

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

The code must be able to be part of the ASF maintained infrastructure. Many 
years and much discussion was done in order to accept GitHub.

Infrastructure supports over 250 projects and podlings, consistency is 
required. Anything non-standard must be supported by the project. Infra has a 
quota of one VM per project.

Regards,
Dave


> 
> Cheers!
> 
> Max



signature.asc
Description: Message signed with OpenPGP


Re: Challenges using Gitbox

2018-04-11 Thread toki
On 04/11/2018 06:11 PM, Maxime Beauchemin wrote:

> 3. The mailing list is a bit dated. I'm saying "a bit" here as an attempt ...
> searchable. Something like Google Groups would be a huge step forward here.

I'd suggest Groups.IO over Google Groups, if only because one of its
features is: "Integration with other services, including: Github, Google
Hangouts, Dropbox, Instagram, Facebook Pages, and the ability to import
Feeds into your groups."

Downside # 1 is that Apache would have to go with either the Premium or
Enterprise option, at US$110/year or US$2200/year, respectively.
Furthermore, I'm not sure the 1TB storage space would suffice.

Downside # 2 is GDPR. Groups.IO is hoping that it won't apply to them.
I can see the EU commission going after both ASF and Groups.IO, if it
isn't in full compliance with GDPR. OTOH, how compliant with GDPR are
any of the ASF projects?

jonathon

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org