Skip to content

Conversation

@smola
Copy link
Contributor

@smola smola commented Oct 17, 2018

Project template

  • Added a directory project-template to use as a template for new projects. 9dc57b1
  • document directory is still preserved for annex documents that do not belong to projects, as well as some symlinks to avoid breaking a lot of links we have to these files.
  • Add MAINTAINERS file template.
  • Put ISSUE_TEMPLATE.md in .github/.
  • Moved CODE_OF_CONDUCT.md and CONTRIBUTING.md to docs/. db56175

Fixes #93

Licensing

Absorbed #305 here:

  • use Apache License 2.0 verbatim text. ebc193c
  • use GPLv3 verbatim text d0f99dc

Plus some small changes:

  • add NOTICE files, these are the ones where we put copyright holder and year 55f2b7c
  • use GPL-3.0 or later wording, as recommended by the FSF 840e686
  • use .md extension for LICENSE and NOTICE, as discussed in this PR. 3fd5f2d

Next steps

Some changes are pending but excluded form this PR to avoid more bloat and easier review:

@smola smola requested review from campoy and mcuadros October 17, 2018 10:04
@smola smola requested a review from jorgeschnura as a code owner October 17, 2018 10:04
@smola smola changed the title add project-template directory, fixes #93 add project-template directory Oct 31, 2018
@mcuadros
Copy link
Contributor

mcuadros commented Nov 7, 2018

sorry you have a conflict

Copy link
Contributor

@dpordomingo dpordomingo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for this, I love it!

LGTM

What about of documenting this into engineering/documentation.md? imho it could be also a good idea to document how to locally configurate the init.templatedir as you suggested by #93 (comment)

I have three more questions/suggestions 👇

@@ -0,0 +1,23 @@
### _Type_:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not storing ISSUE_TEMPLATE.md into .github dir?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 for ISSUE_TEMPLATE.md, since it's purely internal to GitHub. I'm not sure about the others.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that the things that are purely GitHub specific could go into .github while the rest could be inside docs (and GitHub will still find them correctly)

@@ -0,0 +1,73 @@
# Contributor Covenant Code of Conduct
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not pointing each {{repo}}/CODE_OF_CONDUCT.md to https://github.com/src-d/guide/blob/master/.github/CODE_OF_CONDUCT.md as we do with CONTRIBUTING.md, so that way we'll have only one version of that one?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's a good idea to avoid repetition, yeah

@@ -0,0 +1,13 @@
# Contribution Guidelines
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're adding more and more files to the project root which aren't (hardly) related to the application/library itself. I wonder if moving some files to different directories could help to reduce the number of extra files; in this case, I'm wondering about what if we move into .github dir CODE_OF_CONDUCT.md and CONTRIBUTING.md

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking the same. If we don't wanna move it into .github to avoid "vendor lock-in" at least we could move it into the docs directory.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't know that CONTRIBUTING.md could be also stored in docs dir!!!
and it does https://help.github.com/articles/setting-guidelines-for-repository-contributors/

So yes... I'd prefer it too

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will move this to a separate PR.

Copy link
Contributor

@campoy campoy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very cool, I'd also add a note regarding whether we should modify the LICENSE file or not (many have asked about this before).

@@ -0,0 +1,13 @@
# Contribution Guidelines
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking the same. If we don't wanna move it into .github to avoid "vendor lock-in" at least we could move it into the docs directory.

@@ -0,0 +1,13 @@
# Contribution Guidelines

As all source{d} projects, this project follows the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Like all other source{d} projects,

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll move this to a separate PR.

@@ -0,0 +1,23 @@
### _Type_:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that the things that are purely GitHub specific could go into .github while the rest could be inside docs (and GitHub will still find them correctly)

same "printed page" as the copyright notice for easier
identification within third-party archives.

Copyright 2017 Sourced Technologies, S.L.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is 2017 the right number to keep here? Should we keep these updated or write them only once?
For other projects, we've rejected PRs replacing Copyright [yyyy] [name of copyright owner] with this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW, for whatever this is worth on Copyright [year] conventions/legal considerations:

Even in the software licensing roundtable the Linux Foundation organized last year, with all sorts of very high profile people specialized in licensing from OSS world & large corporates, there was no agreement whatsoever on what's the "correct" or "best" practice for this matter, nor if there's any need to update it every year, or provide a range of years…

Copy link
Contributor Author

@smola smola Nov 28, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Year should not be there at all (in that appendix specifically). We discussed about adding NOTICE file for proper copyright notices. This is the Apache Foundation approach, see more here: #305

@marnovo The ASF says the following about NOTICE:

The top of each NOTICE file should include the following text, suitably modified to reflect the product name and year(s) of distribution of the current and past versions of the product:

The FSF says:

To update the list of year numbers, add each year in which you have made nontrivial changes to the package. (Here we assume you’re using a publicly accessible revision control server, so that every revision installed is also immediately and automatically published.) When you add the new year, it is not required to keep track of which files have seen significant changes in the new year and which have not. It is recommended and simpler to add the new year to all files in the package, and be done with it for the rest of the year.

So I assume that the safest choice is including every year in which the project received any non-trivial change.

At least that's ASF and FSF position, which is validated by many years of legal teams crafting copyright policies that can be applied by developers themselves. So sometimes they make rules of thumb that are easily applicable and are overly cautious.

Copy link
Member

@marnovo marnovo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice one. 👍

@@ -0,0 +1,36 @@
Developer Certificate of Origin
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the standard for DCO file not carrying the .md extension? Asking this because in some cases CONTRIBUTING, CODE_OF_CONDUCT, LICENSE have .md extension, others they don't…

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're omitting .md in LICENSE files (what also causes problems in GitBook documentation). GitHub accepts both options, so since it would also fix the problem with links to License in GitBook, I'd choose the .md version

I found no info about DCO but it worths to follow GitHub expectations because doing so it will be shown in PRs (for example)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's move the DCO thing to a separate PR.

education, socio-economic status, nationality, personal appearance, race,
religion, or sexual identity and orientation.

## Our Standards
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice ones

## Enforcement

Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported by contacting the project team at conduct@sourced.tech. All
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just make sure conduct@sourced.tech is working + distributes to the right people (i.e. not an additional email someone has to check).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that I've just moved the file. I assume this was already done when the CoC was put in place.
cc @campoy @eiso

@smola smola force-pushed the repo-tpl branch 2 times, most recently from 7eb67a6 to 840e686 Compare November 28, 2018 15:05
@smola
Copy link
Contributor Author

smola commented Nov 28, 2018

@campoy @dpordomingo @marnovo Could you review again? See the updated PR description. I have incorporated some feedback, absorbed #305 here (since it was being discussed together) and listed some changes that we can move to separate PRs.

cc @mcuadros

@dpordomingo dpordomingo self-requested a review November 28, 2018 15:54
@@ -0,0 +1,15 @@
Copyright (C) 2018 Sourced Technologies, S.L.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From the GPL full text, it is recommended to start with:
<one line to give the program's name and a brief idea of what it does.>

@dpordomingo
Copy link
Contributor

dpordomingo commented Dec 14, 2018

Is this ready to be merged?

@smola smola mentioned this pull request Dec 17, 2018
@smola
Copy link
Contributor Author

smola commented Dec 17, 2018

@dpordomingo Not without review of at least one person from management since this has implications on licensing.

@campoy
Copy link
Contributor

campoy commented Jan 11, 2019

I already approved this, but probably worth having someone else review the licensing concerns.

Maybe @eiso or @jorgeschnura can weigh in?

@bzz
Copy link
Contributor

bzz commented Feb 25, 2019

@smola this is very nice! In order to be merged, a conflict with the latest master needs to be resolved, I presume.

@dpordomingo
Copy link
Contributor

dpordomingo commented Oct 23, 2019

This PR contains relevant info that is already being used by the facto by many company repos as sourced-ce. I reviewed pending comments, and they were going to be addressed in different PRs, so it would be great if we could merge this and iterate later.
wdyt @smola ?

I also resolved the conflicts force-pushing the repo-tpl branch from 40b7ad1 to 4380083

smola added 6 commits October 23, 2019 08:40
The final text where we were adding year and copyright holder name
is just *an appendix about how to add a notice*, not the notice itself.

As found in https://www.apache.org/licenses/LICENSE-2.0.txt

Signed-off-by: Santiago M. Mola <santi@mola.io>
As found in https://www.gnu.org/licenses/gpl-3.0.txt

Signed-off-by: Santiago M. Mola <santi@mola.io>
Signed-off-by: Santiago M. Mola <santi@mola.io>
Signed-off-by: Santiago M. Mola <santi@mola.io>
Add NOTICE.apache and NOTICE.gpl. One of these should be included
for Apache or GPL licenses.

Signed-off-by: Santiago M. Mola <santi@mola.io>
This allows proper integration with tools such as Gitbook.

Signed-off-by: Santiago M. Mola <santi@mola.io>
smola and others added 2 commits October 23, 2019 08:47
Signed-off-by: Santiago M. Mola <santi@mola.io>
Co-Authored-By: smola <santi@mola.io>
@dpordomingo dpordomingo merged commit 2ec75fd into master Nov 29, 2019
@dpordomingo dpordomingo deleted the repo-tpl branch November 29, 2019 09:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Define a project skeleton

7 participants