Re: Proposed policy change: Don't require CLA from contributos

[Lalish-Menagh, Trevor]

That sounds great. Lowering the barrier of entry is always good!

One thing that I am working on with the TODO Group is a tool for
ensuring compliance to repo rules (like Copyright headers):
https://github.com/todogroup/repolinter Might be useful here if we
could tie it in somehow.

On Wed, Jun 21, 2017 at 3:47 AM, Daniel Dekany  wrote:
> Currently we strictly require a CLA (by which I mean an ICLA or CCLA)
> for any contributions to be accepted, as
> http://freemarker.org/contribute.html says.
>
> This practice was inherited from the pre-ASF times, when without
> lawyers available, we tried to be on the safe side. But based on
> https://issues.apache.org/jira/browse/LEGAL-156 and
> https://wiki.apache.org/couchdb/CommitPolicy and some other mails we
> can make things simpler for contributors (not to be confused with
> committers).
>
> So I propose that we say that:
>
> - People sending contributions with GitHub pull requests need no CLA.
>   But, before merging, we must check that:
>   - The mail about the pull request was received to
> notificati...@freemarker.incubator.apache.org, so that there's
> a record of this even in the ASF infrastructure.
>   - The files in the pull request has the standard ASF copyright
> headers, or no copyright headers in files where that's normally
> not present. There's no other conflicting copyright information
> included either (like a such LICENSE file).
> - People sending in patches as attachment to FreeMarker Jira issues
>   need no CLA. But, before merging, we must check that:
>   - It's clear from the wording of the issue that the user wishes to
> contribute (as opposed to, for example, just showing an example).
>   - Copyright headers are in order, just as with GitHub pull request.
>
> If someone contributes a bigger feature, yet they isn't a committer,
> we might still ask a CLA though. But that can be dealt with when such
> thing happens.
>
> --
> Thanks,
>  Daniel Dekany
>



-- 
Trevor Lalish-Menagh
about.me/trevmex

Re: [FM3] Call syntax, positional and named parameters

[Daniel Dekany]

Friday, June 16, 2017, 8:41:37 PM, Daniel Dekany wrote:

> A problem in FM2 is that when calling a directive (as a macro), either
> all parameters are positional (`<@message "Hi" 2 />`), or all
> parameters are named (`<@message content="Hi" height=2 />`); you can't
> mix the two (`<@message "Hi" height=2 />`). Also you can't use named
> parameters for functions/methods, only for directives. Worse, core
> directives don't even use named parameters, but some keyword like
> `as`, `using`... their syntax is hard coded into the parser, which is
> not nice, and will be a problem for the custom dialects feature.
>
> I think that with the exception of a few core directives (see them
> later) all directive calls should be like this, if for now (in this
> thread) we ignore loop variables:
>
>   <#name posPar1 posPar2 namedPar1Name=namedPar1Value 
> namedPar2=namedPar2Value>

An adjustment to the above... I think that we should require comma
between positional arguments (but not between positional and named
arguments and between named arguments):

  <#name posPar1, posPar2 namedPar1Name=namedPar1Value namedPar2=namedPar2Value>

FM2 supports both the <@foo 1, 2, 3 /> and <@foo 1 2 3 /> variation
(and has no core directive with more the one positional argument,
hence I demonstrated it with a custom directive). I believe it's
better stick to one syntax or the other in FM3, not supporting both.
Question is, which one.

While <@foo 1 2 3 /> fits HTML style better, it can be ambiguous.
Consider:

- In `<@foo x - 1 />` is the argument `x - 1`, or we have an `x` and a `-1` 
argument?

- In `<@foo x! 1 />` is the argument `x!1`, or we have an `x!` and a `1` 
argument?

Technically, you can make whitespace significant, so that `<@foo x -1 />`
and `<@foo x - 1 />` has different meaning, but its a quite extreme
syntax design, and when you writing templates, I doubt many users will
even realize that such subtle rules exist. With comma, it's obvious to
do (`<@foo x - 1 />` VS `<@foo x, -1 />`, or even `<@foo x, - 1 />`). It
looks a bit odd next to named parameters, but certainly by far the
most common application of mixed positional and named parameters is
when you have only one positional parameters (<@launch rocket1 delay=3 />),
in which case the comma doesn't appear anyway.

For function calls, which follow typical C-ish expression syntax,
using commas even between named parameters is the natural thing (as in
`f(1, 2, foo=3, bar=4)`), so I would stick to that.

[snip]
> parameters is `<#ftl outputFormat='RTF'>`. So far it's the same as in
> FM2. But now we could have both in once call, such as
> `<#visit node handlers=myNamespace>` (regular syntax), which was
> `<#visit node using myNamespace>` in FM2 (irregular syntax hard coded
> into the parser).
[snip]

For completeness, let's see what other non-regular core directives we
have.

- For #import I would switch to assignment-like approach:
  FM2: <#import "foo.ftl" as f> <#import "bar.ftl" as b>
  FM3: <#import f="foo.ftl" b="bar.ftl">

- #escape doesn't mater, as it will be removed (in favor of output
  formats introduced in 2.3.24).

- #assign has this `in` thing, like `<#assign x = 1 in ns>`. We will
  want to allow <#assign ns.x = 1> (actually, #set) anyway, so that
  won't mater either.

-- 
Thanks,
 Daniel Dekany

Re: Is Freemarker becoming too process heavy? (was Re: Proposed policy change: Don't require CLA from contributos)

[Daniel Dekany]

Wednesday, June 21, 2017, 2:52:08 PM, John D. Ament wrote:

> All,
>
> I'm concerned with some of these threads I'm seeing w/r/t Freemarker.
> While I'm not a mentor on the project, I've been a user for a while and
> have been curious about Freemarker at Apache.
>
> I would not cite a CouchDB process from their old wiki.  First, its not
> clear if this is the most recent version (it mentions a migration to the
> new wiki and an external website which are red flags to me).

(It's not in their new Wiki... But then let's ignore it. There's still
LEGA-156.)

> Second, CouchDB has a much different model and contributor set than
> other projects do.
>
> I would cite a legal JIRA, and as far as I know everyone was already
> following this guide.
>
> I would also cite our legal guidelines
> https://www.apache.org/licenses/#clas in
> particular where it makes sense to expect an ICLA on file.  In general, ASF
> expects ICLAs for large enough contributions.  The size is at the
> discretion of the PMC receiving the contribution.  We do require ICLAs for
> committers to join a project (to receive an account, to receive write
> access) and many projects simply follow that model - you need an ICLA at
> that point in time.

I think what I'm proposing is pretty much the same, only it tells more
concrete details (which I believe is good for Committers who has to
merge stuff; or at least I find the ASF documentations pretty
scattered and at some places superficial). What am I missing?

As of https://www.apache.org/licenses/#clas, it says that:

  The ASF desires that all contributors of ideas, code, or
  documentation to any Apache projects complete, sign, and submit via
  email an Individual Contributor License Agreement (ICLA).

I doesn't talk about exceptions where an ICLA is not needed. But,
today I saw a thread on members@ where someone said ICLA is not needed
for mere contributors, only for Committers, and that led me to
https://issues.apache.org/jira/browse/LEGAL-156, where Legal says no
ICLA is needed for GitHub pull requests, etc.

> I would encourage Freemarker to keep things simple, especially since the
> total number of contributors is at 13.

But that's exactly why I wanted this. It is simpler for contributors
if they can just do a PR, without any paper work.

What do you mean by FM becoming process heavy? Which other threads do
you find concerning?

> John
>
> On Wed, Jun 21, 2017 at 6:48 AM Daniel Dekany  wrote:
>
>> Currently we strictly require a CLA (by which I mean an ICLA or CCLA)
>> for any contributions to be accepted, as
>> http://freemarker.org/contribute.html says.
>>
>> This practice was inherited from the pre-ASF times, when without
>> lawyers available, we tried to be on the safe side. But based on
>> https://issues.apache.org/jira/browse/LEGAL-156 and
>> https://wiki.apache.org/couchdb/CommitPolicy and some other mails we
>> can make things simpler for contributors (not to be confused with
>> committers).
>>
>> So I propose that we say that:
>>
>> - People sending contributions with GitHub pull requests need no CLA.
>>   But, before merging, we must check that:
>>   - The mail about the pull request was received to
>> notificati...@freemarker.incubator.apache.org, so that there's
>> a record of this even in the ASF infrastructure.
>>   - The files in the pull request has the standard ASF copyright
>> headers, or no copyright headers in files where that's normally
>> not present. There's no other conflicting copyright information
>> included either (like a such LICENSE file).
>> - People sending in patches as attachment to FreeMarker Jira issues
>>   need no CLA. But, before merging, we must check that:
>>   - It's clear from the wording of the issue that the user wishes to
>> contribute (as opposed to, for example, just showing an example).
>>   - Copyright headers are in order, just as with GitHub pull request.
>>
>> If someone contributes a bigger feature, yet they isn't a committer,
>> we might still ask a CLA though. But that can be dealt with when such
>> thing happens.
>>
>> --
>> Thanks,
>>  Daniel Dekany
>>
>>

-- 
Thanks,
 Daniel Dekany

Is Freemarker becoming too process heavy? (was Re: Proposed policy change: Don't require CLA from contributos)

[John D. Ament]

All,

I'm concerned with some of these threads I'm seeing w/r/t Freemarker.
While I'm not a mentor on the project, I've been a user for a while and
have been curious about Freemarker at Apache.

I would not cite a CouchDB process from their old wiki.  First, its not
clear if this is the most recent version (it mentions a migration to the
new wiki and an external website which are red flags to me).  Second,
CouchDB has a much different model and contributor set than other projects
do.

I would cite a legal JIRA, and as far as I know everyone was already
following this guide.

I would also cite our legal guidelines https://www.apache.org/licenses/#clas in
particular where it makes sense to expect an ICLA on file.  In general, ASF
expects ICLAs for large enough contributions.  The size is at the
discretion of the PMC receiving the contribution.  We do require ICLAs for
committers to join a project (to receive an account, to receive write
access) and many projects simply follow that model - you need an ICLA at
that point in time.

I would encourage Freemarker to keep things simple, especially since the
total number of contributors is at 13.

John

On Wed, Jun 21, 2017 at 6:48 AM Daniel Dekany  wrote:

> Currently we strictly require a CLA (by which I mean an ICLA or CCLA)
> for any contributions to be accepted, as
> http://freemarker.org/contribute.html says.
>
> This practice was inherited from the pre-ASF times, when without
> lawyers available, we tried to be on the safe side. But based on
> https://issues.apache.org/jira/browse/LEGAL-156 and
> https://wiki.apache.org/couchdb/CommitPolicy and some other mails we
> can make things simpler for contributors (not to be confused with
> committers).
>
> So I propose that we say that:
>
> - People sending contributions with GitHub pull requests need no CLA.
>   But, before merging, we must check that:
>   - The mail about the pull request was received to
> notificati...@freemarker.incubator.apache.org, so that there's
> a record of this even in the ASF infrastructure.
>   - The files in the pull request has the standard ASF copyright
> headers, or no copyright headers in files where that's normally
> not present. There's no other conflicting copyright information
> included either (like a such LICENSE file).
> - People sending in patches as attachment to FreeMarker Jira issues
>   need no CLA. But, before merging, we must check that:
>   - It's clear from the wording of the issue that the user wishes to
> contribute (as opposed to, for example, just showing an example).
>   - Copyright headers are in order, just as with GitHub pull request.
>
> If someone contributes a bigger feature, yet they isn't a committer,
> we might still ask a CLA though. But that can be dealt with when such
> thing happens.
>
> --
> Thanks,
>  Daniel Dekany
>
>

Proposed policy change: Don't require CLA from contributos

[Daniel Dekany]

Currently we strictly require a CLA (by which I mean an ICLA or CCLA)
for any contributions to be accepted, as
http://freemarker.org/contribute.html says.

This practice was inherited from the pre-ASF times, when without
lawyers available, we tried to be on the safe side. But based on
https://issues.apache.org/jira/browse/LEGAL-156 and
https://wiki.apache.org/couchdb/CommitPolicy and some other mails we
can make things simpler for contributors (not to be confused with
committers).

So I propose that we say that:

- People sending contributions with GitHub pull requests need no CLA.
  But, before merging, we must check that:
  - The mail about the pull request was received to
notificati...@freemarker.incubator.apache.org, so that there's
a record of this even in the ASF infrastructure.
  - The files in the pull request has the standard ASF copyright
headers, or no copyright headers in files where that's normally
not present. There's no other conflicting copyright information
included either (like a such LICENSE file).
- People sending in patches as attachment to FreeMarker Jira issues
  need no CLA. But, before merging, we must check that:
  - It's clear from the wording of the issue that the user wishes to
contribute (as opposed to, for example, just showing an example).
  - Copyright headers are in order, just as with GitHub pull request.

If someone contributes a bigger feature, yet they isn't a committer,
we might still ask a CLA though. But that can be dealt with when such
thing happens.

-- 
Thanks,
 Daniel Dekany