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 <[email protected]> : > 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 <[email protected]> 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/ipzill >> a/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 >> [email protected] >> 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 > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/incubation > >
_______________________________________________ incubation mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/incubation
