Re: Recognizing non-code contributions

[William Shen]

Not sure where this thread is heading toward, but I find the role
definition listed on
http://www.apache.org/foundation/how-it-works.html#roles clarifying and
well defined, though they seem to vary slightly from what is on
https://community.apache.org/contributors/. Not sure which one is more
authoritative.

In the context of this thread, here is the difference as I see it:

On www.apache.org 
,

> A *committer* is a *developer* that was given write access to the code
> repository and has a signed Contributor License Agreement (CLA) on file.
> A *developer* is a *user* who contributes to a project in the form of *code
> or documentation*.

Hence, a committer is a user, who contributes code or documentation, that
was given write access to the repository.

On community.apache.org ,

> Committer is a term used at the ASF to signify someone who is committed to
> a particular project. It brings with it the privilege of write access to
> the project repository and resources.
> The foundations of an Apache project and how the community contributes to
> it is sometimes referred to by the acronym CoPDoC: (Co)mmunity - one must
> interact with others, and share vision and knowledge (P)roject - a clear
> vision and consensus are needed (Do)cumentation - without it, the stuff
> remains only in the minds of the authors (C)ode - discussion goes nowhere
> without code
> once someone has contributed sufficiently to any area of CoPDoC they can
> be voted in as a committer.

Hence, a committer is someone, who has contributed sufficiently to *any*
area of Community, Project, Documentation, and Code, that has been given
write access to the project repository and resources.

The key difference between the two definitions is: Can someone, who
contribute significantly in the area of Community or Project without
contribution to Documentation nor Code, be a committer? According to
www.apache.org ,
no; according to community.apache.org
, yes. And that difference
seems to be a main point of discussion here.

By www.apache.org ,
a committer seems to be a role designed to create a subset of users to
"making short-term decisions for the project," and I think that reference
to the ability to commit a patch for Code or Documentation in the project's
repository or resources. And I think that is sensible, and may be in
support of limiting committership to those, who contribute sufficiently
code or documentation to a project's repository or resources, that the
project invites to make future commit decisions for the project.

On Wed, Aug 7, 2019 at 6:07 AM Hyukjin Kwon  wrote:

> > Currently, I have heard some ideas or attitudes that I consider to be
> overly motivated by fear of unlikely occurrences.
> > And I've heard some statements disregard widely accepted principles of
> inclusiveness at the Apache Software Foundation.
> > But I suspect that there's more to the attitude of not including
> non-coding committers at Spark.
>
> I missed some contexts you mentioned. Yes, SVN and commons look good
> examples.
> Also, for clarification, I did not mean to absolutely do not add
> non-codding committers.
> Spark already has build/config committer and I am happy with that.
>
> I was replaying to "the risk is very small". Given my experience in Spark
> dev, people (and I) make mistakes
> which, for instance, blocks the release months. Sometimes it requires to
> rewrite whole PRs with courtesy
> (rather than, for instance, reverting). This is already happening and it
> brings some overhead to the dev.
> Yes, maybe the volume matters to handle those issues.
>
> The point I was trying to make was commit bit could be a too strong sword
> and might have to be
> given and used with familiarity and caution.
>
> For clarification, I have no issue except one concern above for the fact
> that someone becomes a non-code committer since Spark already has it.
>
>
> 2019년 8월 7일 (수) 오후 6:04, Myrle Krantz 님이 작성:
>
>>
>>
>> On Tue, Aug 6, 2019 at 7:57 PM Sean Owen  wrote:
>>
>>> On Tue, Aug 6, 2019 at 11:45 AM Myrle Krantz  wrote:
>>> > I had understood your position to be that you would be willing to make
>>> at least some non-coding contributors to committers but that your "line" is
>>> somewhat different than my own.   My response to you assumed that position
>>> on your part.  I do not think it's good for a project to accept absolutely
>>> no non-code committers.  If nothing else, it violates my sense of fairness,
>>> both towards those contributors, and also towards the ASF which relies on a
>>> pipeline of non-code contributors who come to us through the projects.
>>>
>>> Oh OK, I thought this argument was made repeatedly: someone who has
>>> not and evidently will not ever commit anything to a 

Re: Unsubscribe

[William Shen]

Vinod,
You can send an email to dev-unsubscr...@spark.apache.org to unsubscribe.
You should receive an email with instruction to confirm the unsubscribe.

On Sun, Mar 31, 2019 at 7:42 AM Vinod V Rangayyan 
wrote:

> I wish to unsubscribe from dev@spark.apache.org
>
>
>
>
> On Mar 31, 2019, at 10:07 AM, Rubén Berenguel 
> wrote:
>
> I favour using either $”foo” or columnar expressions, but know of several
> developers who prefer single quote syntax and consider it a better practice.
>
> R
>
> On 31 March 2019 at 15:15:00, Sean Owen (sro...@apache.org) wrote:
>
>> FWIW I use "foo" in Pyspark or col("foo") where necessary, and $"foo" in
>> Scala
>>
>> On Sun, Mar 31, 2019 at 1:58 AM Reynold Xin  wrote:
>>
>>> As part of evolving the Scala language, the Scala team is considering
>>> removing single-quote syntax for representing symbols. Single-quote syntax
>>> is one of the ways to represent a column in Spark's DataFrame API. While I
>>> personally don't use them (I prefer just using strings for column names, or
>>> using expr function), I see them used quite a lot by other people's code,
>>> e.g.
>>>
>>> df.select('id, 'name).show()
>>>
>>> I want to bring this to more people's attention, in case they are
>>> depending on this. The discussion thread is:
>>> https://contributors.scala-lang.org/t/proposal-to-deprecate-and-remove-symbol-literals/2953
>>>
>>>
>>>
>>>
>

Re: Unsubscribe

[William Shen]

Please send an email to dev-unsubscr...@spark.apache.org to unsubscribe.
You should receive an email with instruction to confirm the unsubscribe.

On Wed, Feb 20, 2019 at 3:58 PM Reena Agrawal  wrote:

> Unsubscribe pls.
>