Re: [incubation] Policy: Access rights to GitHub Wiki

[Oliver Kopp <kopp.dev@xxxxxxxxx>]

Dear Wayne,

Thank you for clarification.

For the interested readers, the upcoming EPL 2.0 (see https://dev.eclipse.org/mhonarc/lists/epl-discuss/msg00155.html) also covers "documentation source".

OK, then I'll move forward to collect the whole Winery documentation at https://github.com/eclipse/winery/tree/master/docs.

In my current case, I asked a student to convert my Word document to Markdown. So, the content is by me, but the rendering in Markdown (thus, the source itself) is by the student. I just double checked the CQ https://dev.eclipse.org/ipzilla/show_bug.cgi?id=13783 and https://github.com/eclipse/winery/pull/65/files. This contribution is less than 1000 lines and the ECA is correctly in place. So, I will remove the otherwise copyrighted logo (issue raised by Sharon in CQ 13783) and merge right away.

In other words: In the concrete case, I was confused about the line limit (250 [1] vs. 500 vs. 1000 lines [2]). Now, I am at the less-than-1000-LOC case.

Thank you for the quick and helpful answer!

Cheers,

Oliver

[1] Eclipse Foundation Inc., Due Diligence Process, v. 4.8, January, 2012
[2] Eclipse Foundation Inc., Due Diligence Process, v. 5.2, March, 2017

2017-07-12 6:06 GMT+02:00 Wayne Beaton <wayne.beaton@eclipse-foundation.org>:

Documentation is intellectual property that may be included in downstream products just as easily as actual code, so steps need to be take to mitigate the risks associated with that adoption. 

The Eclipse IP Due Diligence Process primarily a matter of intellectual property risk mitigation. The Eclipse IP Policy understands risk in intellectual property and exists to do that work on behalf of our project teams. While I appreciate that you don't want to overwhelm them with additional work, the fact remains that leveraging their expertise in intellectual property management is a critical part of the process.

So... you really need to follow the IP Policy and process regardless of how the documentation is actually represented. Are you expecting many significant contributions (e.g. more than 1000 lines)? I suspect that for most contributions, you'll just need to track the contribution and not necessarily engage the IP Team.

FWIW, it's true that the use of the Eclipsepedia Wiki for documentation represents a bit of a grey area. Contributions there are covered by the website terms of use. Strictly speaking, however, if a project harvests wiki-based information to produce official documentation, the IP Policy applies.

HTH,

Wayne

 

On Mon, Jul 10, 2017 at 6:27 AM, Oliver Kopp <kopp.dev@xxxxxxxxx> wrote:

Hi,

With the Eclipse Winery project (part of SOA), I am developing at GitHub and want to provide ease editing of docs. Thus, I'm going for markdown.

First, I thought, that github-pages are a good idea, because

(i) they support markdown out of the box and

(ii) they are nicely rendered. See http://eclipse.github.io/winery/

(iii) the documentation comes along with the code and can be updated along with a commit.

(iv) Possibility to use GitHub's pull request review system to ensure quality of the updates.

In case, however, a contributor wants to add text to github-pages, the IP process has to be kicked off: The documentation relies inside the "doc" folder of the source code repository. This causes load on the EMO IP team, which I'd like to reduce and not to increase. Thus, I decided for using the GitHub wiki page (i.e., https://github.com/eclipse/winery/wiki in the context of winery). See also https://dev.eclipse.org/ipzilla/show_bug.cgi?id=13783

I accept that the Wiki is not rendered that nicely (point ii), that the documentation is not at the same place as the code (point iii) and that I cannot use GitHub's pull request review system (point iv).

Since contributors are not allowed to edit the Wiki directly, the approach to get content in is via "git magic": The contributor clones the wiki locally, does the edits and pushes the changes to a git repository X. I fetch from X, review the changes and push the changes to the Eclipse.

Is this workflow intended? Acceptable? What do other projects do for their documentation. What is best practice?

When seeing https://eclipse.org/che/, I think, I should generate a GitHub repository "winery-homepage", which uses Jekyll to generate the HTML files and then "push" the generated HTMLs to the Eclipse infrastructure. So, I could take the advantages of (i), (ii) and (iv).

WDYT?

Cheers,

Oliver

_______________________________________________
incubation mailing list
incubation@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/incubation

--

Wayne Beaton

Director of Open Source Projects

The Eclipse Foundation

_______________________________________________
incubation mailing list
incubation@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/incubation