Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [incubation] Policy: Access rights to GitHub Wiki

Hi everyone,

to piggyback on this discussion, depending on the documentation system
used it may be impossible to include a copyright header in the
documentation files. Is that a problem in any way?

Cheers,
 Chris

On 12/07/17 13:08, Oliver Kopp wrote:
> 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
> <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
> <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
> <https://dev.eclipse.org/ipzilla/show_bug.cgi?id=13783> and
> https://github.com/eclipse/winery/pull/65/files
> <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@xxxxxxxxxxxxxxxxxxxxxx
> <mailto:wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx>>:
> 
>     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
>     <mailto: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/ <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
>         <https://github.com/eclipse/winery/wiki> in the context of
>         winery). See also
>         https://dev.eclipse.org/ipzilla/show_bug.cgi?id=13783
>         <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 <mailto:incubation@xxxxxxxxxxx>
>         To change your delivery options, retrieve your password, or
>         unsubscribe from this list, visit
>         https://dev.eclipse.org/mailman/listinfo/incubation
>         <https://dev.eclipse.org/mailman/listinfo/incubation>
> 
> 
> 
> 
>     -- 
>     Wayne Beaton
>     Director of Open Source Projects
>     The Eclipse Foundation
> 
>     _______________________________________________
>     incubation mailing list
>     incubation@xxxxxxxxxxx <mailto:incubation@xxxxxxxxxxx>
>     To change your delivery options, retrieve your password, or
>     unsubscribe from this list, visit
>     https://dev.eclipse.org/mailman/listinfo/incubation
>     <https://dev.eclipse.org/mailman/listinfo/incubation>
> 
> 
> 
> 
> _______________________________________________
> 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
> 

Attachment: signature.asc
Description: OpenPGP digital signature


Back to the top