Re: Documenting FSF copyright assignment process

[Konstantin Kharlamov <hi-angel@yandex.ru>]

В Чт, апр 11, 2019 at 16:51, Eli Zaretskii <eliz@gnu.org> 
написал:
>>  Date: Thu, 11 Apr 2019 02:33:21 +0300
>>  From: Konstantin Kharlamov <hi-angel@yandex.ru>
>>  Cc: Richard Stallman <rms@gnu.org>
>> 
>>  I recently went through the signing procedure, and one thing I 
>> didn't
>>  like which can be improved: the specific steps up to sending a mail 
>> to
>>  assign@gnu.org are not documented. In my case I had to send a 
>> private
>>  mail to Eli asking for the assignment form, he sent it back to me 
>> along
>>  with further instructions; then I filled the form and sent it to
>>  assign@gnu.org.
>> 
>>  This is a roundtrip that takes time for both maintainer and a user.
> 
> Don't worry about the maintainer's time.  It took me all of 10 sec to
> respond with the form and the instructions for filling it.
> 
>>  Additionally, users are not even sure if what they're doing is 
>> correct,
>>  e.g. look at the last "assignment"-titled mail on this list, it 
>> starts
>>  with "I'm not sure if it's the right place to ask this". Yes, 
>> neither
>>  was I!
> 
> The only way I can understand this particular aspect of the issue is
> by assuming that people don't read the section in the Emacs manual
> where this is described, the one you quoted in your email, because
> that section explicitly tells to ask on emacs-devel.

Not really. The section I quoted tells to ask any questions on 
emacs-devel, but not to ask for the form/instructions in there. When I 
read that section I'm getting stuck "What do I do now? Yeah, I can ask 
a question on emacs-devel, but that sounds silly, because sure 
somewhere here should be the steps for what to do now". So I'm reading 
the section over and over, then I start googling, reading through a 
bunch of irrelevant stuff on the internet… And only then, as I give 
up, I, depending on the level of frustration, do either of α) lay that 
aside to some distant future, or β) ask a non-confident question here 
about assignment.

> I can understand why this could happen: our user manual, being such a
> large document, it is not the best place to include this information
> and hope that it will be easily discoverable there.  So I've included
> that information near the beginning of CONTRIBUTE, which is about the
> first document potential contributors should read before sending
> patches.
> 
>>  It would really help if the emacs documentation about assignment¹ 
>> has
>>  either α) a paragraph with the form to be sent to assign@gnu.org 
>> and
>>  according instructions, or β) if it has to be documented on another
>>  site, e.g. FSF's, it would help to put a link to emacs 
>> documentation¹
>>  after the words "Copyright assignment is a simple process." (and I 
>> hope
>>  that this would-be referred documentation includes α; preferrably 
>> with
>>  any legal notes — if there will be any — moved somewhere at the
>>  bottom).
> 
> If the FSF places the forms on some official site, and accompany them
> with the necessary instructions about how to choose the correct one
> (yes, there's more than one form), then I agree that we should
> reference that place in our docs.  But I don't think it's right for us
> to include the assignment form(s) in our docs, because we are not the
> source of the document, and don't really have to understand all the
> intricacies of the process, starting with how to choose the correct
> form for each case.  (Gnulib does include the forms in its repository,
> but I don't think this is TRT for any GNU project to do that.)

Although GNU Emacs indeed are not the source for form, however it is 
Emacs that has the mandatory requirement for the assignment. This means 
it is correct for Emacs to have it documented — one way or another.

> I think having the information in CONTRIBUTE will make it much more
> discoverable.  As for the time it takes to ask for the form and send
> it in response, I don't see that as a significant issue.

Okay, maybe it's not an issue for you, because you're used to the 
mailing list, as well as to replies to assignment form inqueries.

But it is an issue for an arbitrary user who wants the form.

First of: there's no requirement for a contributor to be subscribed 
here, since patches go to debbugs site anyway. And a user may not know 
how to use a mailing list: does one have to subscribe? How to 
subscribe? What to do with dozens of mails from the list every day? 
Nowadays you can't reasonably expect arbitrary peoples to know how MLs 
work.

Second: a user may not be a native speaker, so composing a mail may 
take time for that alone reason. You can't expect a contributor to be a 
good speaker either, because they could be e.g. just a student who 
wants to improve the app they're using as part of their paper.

Third: sending to a -devel ML means asking real developers. This may be 
an overwhelming thought, making one to try to avoid that as much as 
possible. I'm telling that from my own past experience: though right 
now I'm comfortable (I work as a developer, I contributed to many 
projects, I just got used to being around developers), but it wasn't 
always true. Just 3-4 years ago I'd be really afraid, thinking "But 
assignment form doesn't sound like a development question, am I sure 
this is correct? Won't they make laugh of me?".

Fourth: sending to an ML means there's a bunch of people, and everyone 
gonna see your mail. If you have social communication problems, for 
example sociophobia, this is a demotivational factor.

Fifth: asking specifically for copyright assignment on ML feels like 
yelling "look everyone, I'm gonna contribute to Emacs!", whereas one 
may not even be sure about usefulness of planned contributions. One may 
just have some thoughts for improvements, but they may not pan out for 
one reason or another. I think this may demotivate anyone, doubly so if 
one has social communication problems.

And don't forget that the factors can be combined! Whereas the fix is 
dead easy: just make it clear how to get the form and instructions 
without any interaction.