Delete DCO references, expanded sections on translation and changenotes.
This commit is contained in:
Russell Keith-Magee
parent
ff7d184070
commit
a191e22c05
18 changed files with 170 additions and 526 deletions
|
|
@ -54,17 +54,19 @@ Documentation
|
|||
|
||||
Is the documentation up to date? Do you think things could be worded
|
||||
differently? Are there missing sections? Do you have an idea for a tutorial
|
||||
that could be written? Please submit a Pull Request!
|
||||
|
||||
Help translate and update this Website
|
||||
---------------------------------------
|
||||
that could be written? Please submit a pull request!
|
||||
|
||||
Is there anything wrong or missing from this website? Please feel free to `make
|
||||
edits <https://github.com/beeware/beeware.github.io>`__ and submit a pull
|
||||
request!
|
||||
|
||||
Want to help translate or update the content of this website? Visit the
|
||||
`translations section </contributing/how/translations>`__.
|
||||
Help translate and update this Website
|
||||
---------------------------------------
|
||||
|
||||
Do you speak a language other than English, and would like to help others
|
||||
have better access to BeeWare documentation? Visit the
|
||||
`translations section </contributing/how/translations>`__ to learn how you
|
||||
can contribute translations of BeeWare documentation.
|
||||
|
||||
Build a real application!
|
||||
--------------------------
|
||||
|
|
@ -93,9 +95,8 @@ any questions or walk you through any problems you may encounter.
|
|||
gutter:
|
||||
|
||||
All Contributions Welcome
|
||||
----------------------------------
|
||||
--------------------------
|
||||
|
||||
But it's not just about code. A successful software project requires
|
||||
documentation, design skills, feedback and bug reports. The BeeWare community
|
||||
acknowledges that all contributions are important - not just the ones that come
|
||||
as a pull request on GitHub.
|
||||
It's not just about code. A successful software project requires documentation, design
|
||||
skills, feedback and bug reports. The BeeWare community acknowledges that all
|
||||
contributions are important - not just the ones that come as a pull request on GitHub.
|
||||
|
|
|
|||
|
|
@ -1,9 +0,0 @@
|
|||
_model: page
|
||||
---
|
||||
title: Guía de `DCO` para principiantes
|
||||
---
|
||||
hide_from_index: yes
|
||||
---
|
||||
body: El proyecto BeeWare utiliza un mecanismo conocido como Certificado de Origen de Desarrollador (*Developer Certificate of Origin* por sus siglas en inglés `DCO </es/contribuir/como-ayudar/dco/que-es/>`__ para gestionar el proceso de asegurar que estamos legalmente autorizados a distribuir todo el código y los activos para el proyecto. Una declaración jurídicamente vinculante que afirma que usted es el creador de su contribución y que desea permitir que BeeWare utilice su trabajo.
|
||||
---
|
||||
summary: Porque a veces los abogados necesitan involucrarse ...
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
_model: page
|
||||
---
|
||||
title: Beginners guide to DCOs
|
||||
---
|
||||
summary: Because sometimes lawyers need to get involved...
|
||||
---
|
||||
hide_from_index: yes
|
||||
---
|
||||
body: The BeeWare project uses a mechanism known as a `Developer Certificate of
|
||||
Origin (DCO) </contributing/how/dco/what>`__ to manage the process of ensuring
|
||||
that we are legally allowed to distribute all the code and assets for the
|
||||
project. A DCO is a legally binding statement that asserts that you are the
|
||||
creator of your contribution, and that you wish to allow BeeWare to use your
|
||||
work.
|
||||
|
|
@ -1,63 +0,0 @@
|
|||
_model: page
|
||||
---
|
||||
title: Sobre los derechos de autor
|
||||
---
|
||||
body:
|
||||
|
||||
El derecho de autor es el derecho, creado en la ley, que otorga al creador de una obra original los derechos exclusivos para decidir cómo se utiliza y distribuye esa obra.
|
||||
|
||||
El derecho de autor se concede, de forma inmediata y por defecto, a la persona que crea una pieza de trabajo, cuando la crean. Si escribes una canción, escribes un libro o escribes algún software, eres el creador de ese trabajo. Y tienes el derecho de decidir cómo se usará esa creación.
|
||||
|
||||
¿Qué es un copyright?
|
||||
----------------------------
|
||||
|
||||
Un copyright - usando la palabra como sustantivo - es propiedad. Es propiedad intelectual. Es algo que se puede comprar y vender. Sólo puede ser propiedad de una sola entidad legal en un momento dado. Si tengo un derecho de autor, y te lo vendo, ahora *tu* tienes los derechos de autor de la obra.
|
||||
|
||||
El derecho de autor no se concede indefinidamente. Se concede por un período de tiempo. En teoría, finalmente expira, y cuando lo hace, la obra vuelve al dominio público. Yo digo en teoría, porque las duraciones de los derechos de autor continúan extendiéndose - pero en teoría, todo trabajo finalmente revertirá al dominio público.
|
||||
|
||||
Si tienes una pieza tangible, física de la propiedad, hay limitaciones obvias en el uso. Éste es mi teléfono. Y si lo tomas sin mi permiso, lo estás robando, y eso es un acto criminal. Pero puedo darte permiso - puedo darte licencia para usar mi teléfono - y entonces que uses mi teléfono no es un acto criminal .
|
||||
|
||||
Dar licencia para usar mi teléfono generalmente no va acompañado de un papeleo legal. Generalmente. Pero podría ser. Si estuviera particularmente preocupado por, digamos, que alguien haga un tweet mientras tenías acceso a mi teléfono, podría hacer que firmaras un acuerdo legalmente vinculante que dice que no harás eso.
|
||||
|
||||
Si decido licenciarte mi teléfono, eso no te da intrínsecamente los derechos de propiedad sobre mi teléfono. Tu no obtienes el derecho de prestar el teléfono a otra persona - a menos que la licencia otorgue ese derecho. Todavía es de *mi* propiedad; solo lo utilizas *bajo licencia*.
|
||||
|
||||
Sin embargo, puedo *darte* o *venderte* mi teléfono - puedo transferirte mi derecho de propiedad. Pero hace una gran diferencia legal si estoy *dándote* mi teléfono, o *licenciándote* el uso de mi teléfono.
|
||||
|
||||
Con suerte, está claro que los términos "copyright" y "license" no son intercambiables - son piezas complementarias del mismo rompecabezas.
|
||||
|
||||
Un pedazo de software es propiedad intelectual. El copyright de una pieza de software es propiedad de alguien - por defecto, el creador. Si deseas utilizar una pieza de software, tienes que ser dado la propiedad - dado el derecho de autor - o concederte una licencia para utilizar el trabajo. Y hace una gran diferencia cuál consigas.
|
||||
|
||||
Copyleft
|
||||
------------
|
||||
Tradicionalmente, se otorgó el derecho de autor para dar a un creador la exclusividad de vender copias de su trabajo. La expectativa era que la gente licenciara copias de su trabajo a cambio de pago.
|
||||
|
||||
Pero a principios de los años 80, la Fundación de Software Libre diseñó un hack legal muy inteligente. Ellos escribieron una licencia de software que, en lugar de defender los derechos del creador, defendían los derechos del receptor.
|
||||
|
||||
El resultado fue copyleft. Copyleft *no* es un sustituto de los derechos de autor. Es un hack legal muy inteligente que *usa* la ley de copyright para hacer cumplir exactamente lo opuesto a lo que el copyright provee. Sin derechos de autor, copyleft no podría existir.
|
||||
|
||||
¿Por qué se requiere una licencia?
|
||||
-----------------------------------------
|
||||
|
||||
Si *no* proporcionas una licencia, los términos de la licencia predeterminados en su creación son "TODOS LOS DERECHOS RESERVADOS" - incluso si no se dice. Esto significa que nadie puede legalmente utilizar tu código. Y si ves código sin licencia claramente establecida, no puedes usar ese código legalmente.
|
||||
|
||||
Esto aplica a cualquier creación, no importa cuán grande o pequeña - cada mejora/contribución que envías a un proyecto para la inclusión es un trabajo creativo; y eso significa que se requiere una licencia.
|
||||
|
||||
Dominio publico
|
||||
---------------------
|
||||
|
||||
Esto probablemente suena como más problemas de lo que se requiere. ¿Por qué no se puede simplemente decir "Bueno, estoy dando esto a la dominio público".
|
||||
|
||||
Como creador de una obra, en algunas jurisdicciones, ciertos derechos *no* pueden ser transferidos.
|
||||
|
||||
Las cuestiones de derecho de autor están estrechamente asociadas con un concepto conocido como Derechos Morales - derechos que se consideran innatos a la experiencia humana. El problema es que el área de los derechos morales es *muy* dependiente de la jurisdicción. Los derechos morales reconocidos por los tribunales europeos -y en particular por los alemanes- son mucho más fuertes que los derechos morales reconocidos por los tribunales de los Estados Unidos de América.
|
||||
|
||||
Por lo tanto, una declaración de que has publicado tu código en el dominio público es en realidad *ilegal* en Alemania. Los tribunales alemanes no reconocerán esa transferencia de propiedad - como tampoco reconocerían un acuerdo legal para vender a sí mismos en la esclavitud. Tu derecho moral a una compensación justa por tu esfuerzo creativo es un derecho moral que se considera inalienable. Y así, tu trabajo vuelve a tener una licencia por defecto: Todos los derechos reservados. Así que los alemanes no pueden usar tu código.
|
||||
|
||||
Certificados de origen del desarrollador
|
||||
--------------------------------------------------
|
||||
|
||||
Hay varias maneras de administrar el proceso de licencias de contribuciones, pero el proyecto BeeWare utiliza un mecanismo conocido como `Certificados de origen del desarrollador -DCO (por sus siglas en inglés) </es/contribuir/como-ayudar/dco/que-es/>`__. Para más detalles sobre lo que es el DCO, y lo que significa, `puedes ver nuestra guía explicativa </es/contribuir/como-ayudar/dco/>`__. Si necesitas ayuda para configurar tu sistema para cumplir con nuestro DCO `tenemos algunas instrucciones paso a paso para ayudarle a realizarlo </es/contribuir/como-ayudar/dco/como-firmar>`__.
|
||||
---
|
||||
sort_key: 1
|
||||
---
|
||||
_slug: derechos-de-autor
|
||||
|
|
@ -1,116 +0,0 @@
|
|||
_model: page
|
||||
---
|
||||
sort_key: 1
|
||||
---
|
||||
title: A copyright primer
|
||||
---
|
||||
body:
|
||||
|
||||
Copyright is the right, created in law, granting a creator of an original work
|
||||
the exclusive rights to decide how that work is used and distributed.
|
||||
|
||||
Copyright is granted, immediately and by default, to the person that creates a
|
||||
piece of work, when they create it. If you write a song, write a book, or write
|
||||
some software - you are the creator of that work. And you have the right to
|
||||
decide how that creation will be used.
|
||||
|
||||
What is a copyright?
|
||||
---------------------
|
||||
|
||||
A copyright - using the word as a noun - is property. It's intellectual
|
||||
property. It's something that can be bought and sold. It can only be owned by a
|
||||
single legal entity at any given time. If I have a copyright, and I sell it to
|
||||
you, you now own it. *You* have the copyright for the work.
|
||||
|
||||
Copyright is not granted indefinitely. It's granted for a period of time. In
|
||||
theory, it eventually expires, and when it does, the work reverts to the public
|
||||
domain. I say in theory, because copyright durations keep being extended - but
|
||||
in theory, all work will eventually revert to the public domain.
|
||||
|
||||
If you've got a tangible, physical piece of property, there are obvious
|
||||
limitations on use. This is *my* phone. And if you take it without my
|
||||
permission, you're stealing it, and that's a criminal act. But I can give you
|
||||
permission - I can give you license to use my phone - and then it isn't a
|
||||
criminal act for you to use my phone.
|
||||
|
||||
Giving you license to use my phone usually won't be accompanied by legal
|
||||
paperwork. Usually. But it could be. If I was particularly worried about, say,
|
||||
you tweeting "pooping" while you had access to my phone, I could get you to
|
||||
sign a legally binding agreement that says you won't do that.
|
||||
|
||||
If I do decide to license my phone to you - that doesn't inherently give you
|
||||
property rights over the phone. You don't get the right to lend the phone to
|
||||
someone else -- unless the license grants you that right. It's still *my*
|
||||
property; you're just *using it under license*.
|
||||
|
||||
However, I can *give* or *sell* you my phone - I can transfer my property right
|
||||
to you. But it makes a big legal difference whether I'm *giving* you my phone,
|
||||
or *licensing* you my phone.
|
||||
|
||||
Hopefully, it's clear that the terms "copyright" and "license" aren't
|
||||
interchangeable - they're complementary pieces of the same puzzle.
|
||||
|
||||
A piece of software is intellectual property. The copyright for a piece of
|
||||
software is owned by someone - by default, the creator. If you want to use a
|
||||
piece of software, you have to be either given ownership - given the copyright
|
||||
- or granted a license to use the work. And it makes a big difference which
|
||||
one you get.
|
||||
|
||||
Copyleft
|
||||
----------
|
||||
Traditionally, copyright was granted to give a creator exclusivity to sell
|
||||
copies of their work. The expectation was that people would license copies of
|
||||
their work in exchange for payment.
|
||||
|
||||
But in the early 80s, the Free Software Foundation engineered a very clever
|
||||
legal hack. They wrote a software license that, rather than defending the
|
||||
rights of the creator, they defended the rights of the recipient.
|
||||
|
||||
The result was copyleft. Copyleft is *not* a replacement for copyright. It's a
|
||||
very clever legal hack that *uses* copyright law to enforce the exact opposite
|
||||
to what copyright was intended to provide. Without copyright law, copyleft
|
||||
couldn't exist.
|
||||
|
||||
Why is a license required?
|
||||
----------------------------
|
||||
|
||||
If you *don't* provide a license, the default licensing terms on your creation
|
||||
are "ALL RIGHTS RESERVED" - even if you don't say that. This means nobody can
|
||||
legally use your code. And if you see code with no clearly offered license, you
|
||||
cannot legally use it.
|
||||
|
||||
This applies to any creation, no matter how big or small - every patch you
|
||||
submit to a project for inclusion is a creative work; and that means a license
|
||||
is required.
|
||||
|
||||
Public Domain
|
||||
--------------
|
||||
|
||||
This probably sounds like a whole lot more trouble than it's worth. Why can't
|
||||
you just say "Well, I'm giving this away to the public domain".
|
||||
|
||||
As the creator of a work, in some jurisdictions, certain rights *cannot* be
|
||||
transferred.
|
||||
|
||||
Issues of copyright are closely associated with a concept known as Moral Rights
|
||||
- rights that are considered innate to the human experience. The problem is
|
||||
that the area of Moral rights is *very* jurisdiction dependent. Moral rights
|
||||
recognized by European - and, in particular, German courts - are *much*
|
||||
stronger than the moral rights recognized by US courts.
|
||||
|
||||
So - a declaration that you've released your code into the public domain is
|
||||
actually *illegal* in Germany. German courts won't recognize that transfer of
|
||||
ownership - any more than they'd recognize a legal agreement to sell yourself
|
||||
into slavery. Your moral right to fair compensation for your creative effort is
|
||||
a moral right that is considered unalienable. And so, your work reverts to its
|
||||
default license: All rights reserved. So Germans then can't use your code.
|
||||
|
||||
Developer Certificates of Origin
|
||||
---------------------------------
|
||||
|
||||
There are a number of ways to manage the process of licensing contributions,
|
||||
but the BeeWare project uses a mechanism known as a `Developer Certificate of
|
||||
Origin </contributing/how/dco/what/>`__. For more details on what DCO is, and
|
||||
what it means, `see our explanatory guide </contributing/how/dco/what/>`__.
|
||||
If you've need help configuring your system to comply with our DCO `we've got
|
||||
some step by step instructions to help you out </contributing/how/dco/how/>`__.
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
_model: page
|
||||
---
|
||||
title: ¿Cómo firmar un 'DCO'?
|
||||
---
|
||||
sort_key: 3
|
||||
---
|
||||
body:
|
||||
|
||||
Para indicar que acepta los términos del Certificado de Origen de Desarrollador (por sus siglas en inglés DCO), simplemente agregue una línea a cada mensaje de envío de git:
|
||||
|
||||
.. code-block::
|
||||
|
||||
Firmado por: Joe Smith <joe.smith@email.com>
|
||||
|
||||
Si configura su `user.name` y `user.email` como parte de su configuración git, puede firmar su commit automáticamente con `git commit -s`.
|
||||
---
|
||||
summary:
|
||||
---
|
||||
incomplete: yes
|
||||
---
|
||||
_slug: como-firmar
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
_model: page
|
||||
---
|
||||
title: How to sign a DCO
|
||||
---
|
||||
summary:
|
||||
---
|
||||
incomplete: yes
|
||||
---
|
||||
sort_key: 3
|
||||
---
|
||||
body:
|
||||
|
||||
To indicate that you agree to the terms of the DCO, you just add a line to
|
||||
every git commit message::
|
||||
|
||||
Signed-off-by: Joe Smith <joe.smith@email.com>
|
||||
|
||||
If you set your user.name and user.email as part of your git configuration, you
|
||||
can sign your commit automatically with ``git commit -s``.
|
||||
|
|
@ -1,59 +0,0 @@
|
|||
_model: page
|
||||
---
|
||||
title: ¿Qué es un DCO?
|
||||
---
|
||||
body:
|
||||
|
||||
El proyecto BeeWare utiliza un mecanimo conocido como `Certificado de origen del Desarrollador - DCO (por sus siglas en inglés) </es/contribuir/como-ayudar/dco/>`__ para administrar este proceso. El DCO es una declaración jurídicamente vinculante que afirma que usted es el creador de su contribución y que desea permitir que BeeWare utilice su trabajo.
|
||||
|
||||
El acuso de recibo de este permiso se realiza mediante un proceso de inicio de sesión en Git. El *sign-off* es una línea simple al final de la explicación para el parche. El texto del DCO es bastante simple (de `developercertificate.org <https://developercertificate.org>`__)::
|
||||
|
||||
Certificado de origen del desarrollador
|
||||
Versión 1.1
|
||||
|
||||
Copyright (C) 2004, 2006 La Fundación Linux y sus colaboradores.
|
||||
660 York Street, Suite 102,
|
||||
San Francisco, CA 94110 USA
|
||||
|
||||
Todo el mundo está autorizado a copiar y distribuir copias
|
||||
documento de licencia, pero no se permite cambiarlo.
|
||||
|
||||
Certificado de origen del desarrollador 1.1
|
||||
|
||||
Al hacer una contribución a este proyecto, certifico que:
|
||||
|
||||
(a) La contribución fue creada total o parcialmente por mí y yo
|
||||
tienen derecho a presentarlo bajo la licencia de código abierto
|
||||
indicada en el expediente; o
|
||||
|
||||
(b) La contribución se basa en trabajos anteriores que, a la mejor
|
||||
de mi conocimiento, está cubierto bajo una fuente abierta apropiada
|
||||
licencia y tengo el derecho bajo esa licencia de presentar
|
||||
trabajo con modificaciones, ya sean creadas en su totalidad o en parte
|
||||
por mí, bajo la misma licencia de código abierto (a menos que sea
|
||||
autorizada a presentar una licencia diferente), según se indica
|
||||
en el archivo; o
|
||||
|
||||
(c) La contribución me fue proporcionada directamente por algún otro
|
||||
persona que certificó (a), (b) o (c) y no he modificado
|
||||
eso.
|
||||
|
||||
(d) Entiendo y estoy de acuerdo en que este proyecto y la contribución
|
||||
pública y que el registro de la contribución (incluida toda la
|
||||
información personal que envío con ella, e incluyendo mi firma) se
|
||||
mantiene indefinidamente y puede ser redistribuida
|
||||
con este proyecto o las licencias de código abierto involucradas.
|
||||
|
||||
Si está dispuesto a aceptar estos términos, simplemente añada una línea a cada mensaje de envío de git::
|
||||
|
||||
Firmado por: Joe Smith <joe.smith@email.com>
|
||||
|
||||
Si configura su ``user.name`` y ``user.email`` como parte de su configuración de git, puede firmar su commit automáticamente con ``git commit -s``.
|
||||
|
||||
Por desgracia, usted tiene que usar su nombre real (es decir, pseudónimos o contribuciones anónimas no se pueden hacer). Esto se debe a que el DCO es un documento jurídicamente vinculante, otorgando al proyecto BeeWare el uso de su trabajo.
|
||||
---
|
||||
sort_key: 2
|
||||
---
|
||||
incomplete: yes
|
||||
---
|
||||
_slug: que-es
|
||||
|
|
@ -1,67 +0,0 @@
|
|||
_model: page
|
||||
---
|
||||
sort_key: 2
|
||||
---
|
||||
incomplete: yes
|
||||
---
|
||||
title: What is a DCO?
|
||||
---
|
||||
body:
|
||||
|
||||
The BeeWare project uses a mechanism known as a `Developer Certificate of
|
||||
Origin (DCO) </contributing/how/dco/>`__ to manage this process. The DCO is a
|
||||
legally binding statement that asserts that you are the creator of your
|
||||
contribution, and that you wish to allow BeeWare to use your work.
|
||||
|
||||
Acknowledgement of this permission is done using a sign-off process in Git. The
|
||||
sign-off is a simple line at the end of the explanation for the patch. The text
|
||||
of the DCO is fairly simple (from `developercertificate.org
|
||||
<https://developercertificate.org>`__)::
|
||||
|
||||
Developer Certificate of Origin
|
||||
Version 1.1
|
||||
|
||||
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
|
||||
660 York Street, Suite 102,
|
||||
San Francisco, CA 94110 USA
|
||||
|
||||
Everyone is permitted to copy and distribute verbatim copies of this
|
||||
license document, but changing it is not allowed.
|
||||
|
||||
Developer's Certificate of Origin 1.1
|
||||
|
||||
By making a contribution to this project, I certify that:
|
||||
|
||||
(a) The contribution was created in whole or in part by me and I
|
||||
have the right to submit it under the open source license
|
||||
indicated in the file; or
|
||||
|
||||
(b) The contribution is based upon previous work that, to the best
|
||||
of my knowledge, is covered under an appropriate open source
|
||||
license and I have the right under that license to submit that
|
||||
work with modifications, whether created in whole or in part
|
||||
by me, under the same open source license (unless I am
|
||||
permitted to submit under a different license), as indicated
|
||||
in the file; or
|
||||
|
||||
(c) The contribution was provided directly to me by some other
|
||||
person who certified (a), (b) or (c) and I have not modified
|
||||
it.
|
||||
|
||||
(d) I understand and agree that this project and the contribution
|
||||
are public and that a record of the contribution (including all
|
||||
personal information I submit with it, including my sign-off) is
|
||||
maintained indefinitely and may be redistributed consistent with
|
||||
this project or the open source license(s) involved.
|
||||
|
||||
If you are willing to agree to these terms, you just add a line to every git
|
||||
commit message::
|
||||
|
||||
Signed-off-by: Joe Smith <joe.smith@email.com>
|
||||
|
||||
If you set your ``user.name`` and ``user.email`` as part of your git
|
||||
configuration, you can sign your commit automatically with ``git commit -s``.
|
||||
|
||||
Unfortunately, you have to use your real name (i.e., pseudonyms or anonymous
|
||||
contributions cannot be made). This is because the DCO is a legally binding
|
||||
document, granting the BeeWare project to use your work.
|
||||
|
|
@ -10,17 +10,17 @@ _slug: setup
|
|||
---
|
||||
body:
|
||||
|
||||
In order to get contributing, you're going to need to setup a
|
||||
**development environment** - a place where you can work on code where it can
|
||||
behave the same as everyone else's environment.
|
||||
In order to get contributing, you're going to need to setup a
|
||||
**development environment** - a place where you can work on code where it can
|
||||
behave the same as everyone else's environment.
|
||||
|
||||
Many parts of BeeWare use the same tools: a specific version of Python, and
|
||||
virtual environment controls.
|
||||
Many parts of BeeWare use the same tools: a specific version of Python, and
|
||||
virtual environment controls.
|
||||
|
||||
Python
|
||||
-----------
|
||||
-------
|
||||
|
||||
Python is a scripting language, which is available on a number of different
|
||||
Python is a scripting language, which is available on a number of different
|
||||
operating systems. However, depending on what system you are using, your
|
||||
version of Python is going to be different. Because of this reason, we specify
|
||||
exactly which version of Python we expect the code to work with.
|
||||
|
|
@ -30,15 +30,15 @@ which version of Python you need to install. Normally, this is listed in the
|
|||
``README.md`` file or in the tutorial information. Our `CI
|
||||
</contributing/how/first-time/what-is-a/ci>`_ systems have to be told exactly
|
||||
which version of Python is required, too. So if you're really stuck, try
|
||||
looking at the :code:`.github/workflows.ci.yml` file for the specific version
|
||||
looking at the :code:`.github/workflows/ci.yml` file for the specific version
|
||||
you need.
|
||||
|
||||
pyenv
|
||||
~~~~~~
|
||||
|
||||
`pyenv <https://github.com/pyenv/pyenv>`_ is a way to get multiple versions of
|
||||
Python working on your machine at the same time. It allows you to pick and
|
||||
choose whichever version you need for a particular project.
|
||||
`pyenv <https://github.com/pyenv/pyenv>`_ is a one way to get multiple versions of
|
||||
Python working on your machine at the same time. It allows you to pick and choose
|
||||
whichever version you need for a particular project.
|
||||
|
||||
* MacOSX - You can install pyenv via `brew
|
||||
</contributing/how/first-time/what-is-a/package-manager>`_, by running
|
||||
|
|
@ -61,48 +61,70 @@ To install and set the Python version:
|
|||
More information about pyenv is available on `their website
|
||||
<https://github.com/pyenv/pyenv/blob/master/COMMANDS.md>`_.
|
||||
|
||||
virtualenv
|
||||
-----------
|
||||
Virtual Environments
|
||||
---------------------
|
||||
|
||||
Once Python is installed, you're going to want to be able to install different
|
||||
Python packages. Since you may have more than one project being worked on, and
|
||||
more than one version of Python, having a way to make sure that only specific
|
||||
Python packages are available at any one time is handy.
|
||||
When Python is installed, it provides a single global environment. By default, if you
|
||||
install a package, it will be installed into this global environment.
|
||||
|
||||
One way we can do this is via `virtualenv
|
||||
<https://virtualenv.pypa.io/en/stable/>`_.
|
||||
However, if you're working on more than one Python project, it's entirely likely that
|
||||
those multiple projects will have different - and in some cases, conflicting -
|
||||
requirements. What you need is a way to isolate each project so that installing a
|
||||
package for one project won't force that same package to be installed for the second
|
||||
project.
|
||||
|
||||
Using `pip </contributing/how/first-time/what-is-a/package-manager>`_, we can
|
||||
install virtualenv:
|
||||
This is done using *Virtual Environments*. A Virtual Environment, or ``venv``, is an
|
||||
isolated environment that can be easily created, destroyed or recreated. Any package
|
||||
installed in the virtual environment is only accessible *inside* that virtual
|
||||
environment. Virtual environments are sometimes referred to as a "sandbox" - a safe
|
||||
place to play, where if you make a mistake, you can knock down everything you've built
|
||||
and start again.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ pip install virtualenv
|
||||
|
||||
Then, we want to setup a virtualenv that we can then activate. Having more than
|
||||
one virtualenv is ok, but only one can be activated at a time. Make sure you
|
||||
have your Python selection done with :code:`pyenv`, so that we know what
|
||||
version of Python to use:
|
||||
Python provides the ``venv`` module to create new virtual environments. Each virtual
|
||||
environment has a name that can be used to identify the environment. To create a fresh
|
||||
virtual environment named "my-venv", run:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ virtualenv -p $(pyenv which python) env
|
||||
|
||||
Then, we can activate the virtual environment:
|
||||
$ python -m venv my-venv
|
||||
|
||||
The version of Python that you use to create the virtual environment will be the version
|
||||
that is used by default *inside* the virtual environment. If you've got multiple Python
|
||||
versions installed, or you're using a tool like ``pyenv`` to manage Python versions,
|
||||
ensure that the Python version that is currently active (or the version you reference
|
||||
when invoking the ``-m venv`` command) is the version you intend. Once a virtual
|
||||
environment has been created, you can't change the Python version that it is using. To
|
||||
change the Python version, you need to create a fresh virtual environment.
|
||||
|
||||
Invoking ``-m venv`` will *create* the virtual environment, but the environment is not
|
||||
yet *active*. The virtual environment is a collection of files on disk, stored in a
|
||||
directory that matches the name of the environment. To activate the virtual environment,
|
||||
you run one of the files generated as part of the environment:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ source env/bin/activate
|
||||
|
||||
This will result in a little note in your command line letting you know you're
|
||||
in a virtual environment:
|
||||
$ source my-venv/bin/activate
|
||||
|
||||
This will result in a prefix being added to your command line prompt letting you know
|
||||
you're in a virtual environment:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
(env) $
|
||||
|
||||
To disable your virtualenv:
|
||||
(my-venv) $
|
||||
|
||||
While the virtual environment is active, any ``pip install`` command will *only* affect
|
||||
the virtual environment. It doesn't matter if you change directories - if your prompt
|
||||
has a prefix, that virtual environment is active.
|
||||
|
||||
If you open a second terminal window, the environment will *not* be active - you need to
|
||||
re-activate the environment in every terminal session where you want to use the
|
||||
environment. If you get errors about libraries not being available that you're *certain*
|
||||
you've installed - check whether your virtual environment is active.
|
||||
|
||||
To deactive the virtual environment, run:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ deactivate
|
||||
|
||||
(my-venv) $ deactivate
|
||||
|
||||
Once deactivated, the prefix will be dropped from the prompt.
|
||||
|
|
|
|||
|
|
@ -6,21 +6,21 @@ summary: What is CI, or Continuous Integration
|
|||
---
|
||||
body:
|
||||
|
||||
Continuous integration, or CI, is a way that we can test code continuously.
|
||||
These systems will automatically listen for new Pull Requests and other events,
|
||||
and automatically run test suites, and other automatic processes.
|
||||
Continuous integration, or CI, is a way that we can test code every change that is made
|
||||
to a project. These systems automatically listen for new pull requests and other events,
|
||||
and automatically run test suites, and other automatic processes.
|
||||
|
||||
We primarily use GitHub's CI system: `Actions
|
||||
We use GitHub's CI system: `Actions
|
||||
<https://github.com/features/actions>`_. Normally the *build status* of a
|
||||
project is displayed as an image on the project's README file. Green means the
|
||||
tests have been successful, and red means they have not. Clicking the image
|
||||
will show you the results of these tests.
|
||||
will show you the results of these tests.
|
||||
|
||||
---
|
||||
gutter:
|
||||
|
||||
Unsure which CI environment is being used?
|
||||
--------------------------------------------------------
|
||||
-------------------------------------------
|
||||
|
||||
Check for the configuration file. Travis uses ``.travis.yml`` and GitHub CI is
|
||||
configured in the ``.github/workflows`` directory.
|
||||
Check for the configuration file. GitHub CI workflows are configured in the
|
||||
``.github/workflows`` directory.
|
||||
|
|
|
|||
|
|
@ -8,22 +8,22 @@ body:
|
|||
|
||||
Installing software on your computer can be interesting. Sometimes you have to
|
||||
download a file and then install it yourself, or copy files to specific places
|
||||
on your computer.
|
||||
on your computer.
|
||||
|
||||
However, ``package managers`` help make this process easier by allowing for the
|
||||
automation of installation of software.
|
||||
However, package managers help make this process easier by allowing for the
|
||||
automation of installation of software.
|
||||
|
||||
There are different levels of package managers: for the operating system level,
|
||||
as well as one specifically for Python packages.
|
||||
as well as one specifically for Python packages.
|
||||
|
||||
MacOSX
|
||||
---------------
|
||||
-------
|
||||
|
||||
`Homebrew <https://brew.sh/>`_ is the standard for installing software on your
|
||||
Mac. This is the system that's used if you run a :code:`brew install` command.
|
||||
Mac. This is the system that's used if you run a :code:`brew install` command.
|
||||
|
||||
Linux
|
||||
------------
|
||||
------
|
||||
|
||||
Depending on what family of operating system you run, you'll use
|
||||
:code:`apt-get` (for Debian and Ubuntu) or :code:`yum` (for Red Hat and CentOS).
|
||||
|
|
@ -31,10 +31,7 @@ Depending on what family of operating system you run, you'll use
|
|||
Python
|
||||
------------
|
||||
|
||||
:code:`pip` is the way you can install Python software. Running :code:`pip
|
||||
install` uses the `Python Packaging Index <https://pypi.python.org/pypi>`_,
|
||||
also known as `PyPI` or "The Cheese Shop"; it's a central repository for Python
|
||||
code. Many BeeWare projects can be installed using `pip`.
|
||||
|
||||
Why is it called "The Cheese Shop"? It's a `Monty Python
|
||||
<https://en.wikipedia.org/wiki/Cheese_Shop_sketch>`_ reference :)
|
||||
:code:`pip` is the way you can install Python software. Running :code:`pip install` uses
|
||||
the `Python Packaging Index <https://pypi.org>`_, also known as "PyPI". PyPI is a
|
||||
central repository for Python code. Many BeeWare projects can be installed using
|
||||
:code:`pip`.
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ est celui qui correspond à vos connaissances, votre expérience, et vos centres
|
|||
d'intérêts.
|
||||
|
||||
Avant de commencer
|
||||
-----------------
|
||||
-------------------
|
||||
|
||||
Avant de commencer à contribuer, cela peut aider d'avoir un ressenti du projet
|
||||
dans son ensemble. Si vous n'avez pas encore complété le `tutoriel BeeWare
|
||||
|
|
@ -27,7 +27,7 @@ qu'elle l'était !), voici quelques idées d'où vous engager, selon vos compét
|
|||
et vos intérêts.
|
||||
|
||||
Programmation Python
|
||||
-------------------
|
||||
---------------------
|
||||
|
||||
Briefcase
|
||||
~~~~~~~~~
|
||||
|
|
@ -67,7 +67,7 @@ La documentation de Colosseum a un `guide de contribution
|
|||
vous mener à travers votre première contribution à Colosseum.
|
||||
|
||||
Programmation avec interface graphique
|
||||
----------------
|
||||
---------------------------------------
|
||||
|
||||
Si vous avez de l'expérience avec une bibliothèque de widgets natifs — Cocoa sur
|
||||
macOS, GTK+ sur Linux, Windows Forms, ou les bibliothèques natives iOS ou Android,
|
||||
|
|
@ -143,7 +143,7 @@ rencontrez des problèmes, signalez-les comme des bogues ; si vous êtes témér
|
|||
voyez si vous trouvez comment *résoudre* le bogue.
|
||||
|
||||
Utilisation pratique
|
||||
----------------
|
||||
---------------------
|
||||
|
||||
Un des meilleurs moyens pour nous de déterminer où sont nos lacunes – tant dans
|
||||
la documentation que les APIs – est que des gens utilisent réellement BeeWare pour
|
||||
|
|
@ -169,7 +169,7 @@ summary: Alors vous voulez aider – mais où devriez-vous commencer ?
|
|||
gutter:
|
||||
|
||||
Première contribution
|
||||
------------------------
|
||||
----------------------
|
||||
|
||||
Vous voulez commencer petit ? Une fois que vous aurez commencé à explorer les tutoriels,
|
||||
jetez un œil aux problèmes marqués `[good first issue]
|
||||
|
|
|
|||
|
|
@ -9,28 +9,31 @@ summary: The BeeWare development process
|
|||
body:
|
||||
|
||||
Overview
|
||||
---------------
|
||||
---------
|
||||
|
||||
All changes, for code and documentation, should be `submitted
|
||||
</contributing/how/first-time/github/>`_ via a Pull Request to the GitHub
|
||||
repository for the project.
|
||||
All changes to code and documentation should be `submitted
|
||||
</contributing/how/first-time/github/>`_ via a pull request to the GitHub repository for
|
||||
the project.
|
||||
|
||||
Most of the projects have a dedicated Contributing guide with specifics for
|
||||
that project that can be found on ReadTheDocs. For instance, Briefcase's `guide
|
||||
<https://briefcase.readthedocs.io/en/stable/how-to/contribute-code.html>`__ for
|
||||
contributing code.
|
||||
Most projects have a dedicated contribution guide with details specific to that project,
|
||||
or specific types of contribution. This documentation can be found on Read the Docs. For
|
||||
example, `Briefcase's documentation <https://briefcase.readthedocs.io>`__ contains
|
||||
contribution guides for both `code
|
||||
<https://briefcase.readthedocs.io/en/stable/how-to/contribute-code.html>`__ and
|
||||
`documentation
|
||||
<https://briefcase.readthedocs.io/en/stable/how-to/contribute-docs.html>`__.
|
||||
|
||||
All submissions should abide by the `Code of Conduct
|
||||
All submissions should abide by the `BeeWare Code of Conduct
|
||||
</community/behavior/code-of-conduct/>`_.
|
||||
|
||||
Change Notes
|
||||
---------------
|
||||
-------------
|
||||
|
||||
Several BeeWare projects, notably Briefcase and Toga, require each Pull Request
|
||||
is submitted with a change note. These change notes are compiled together when
|
||||
a Release is cut for the project to serve as Release Notes for users.
|
||||
Several BeeWare projects, notably Briefcase and Toga, require that each pull request is
|
||||
submitted with a change note. These change notes are compiled together when a new
|
||||
release is cut for the project, producing the release notes for the new release.
|
||||
|
||||
`Towncrier <https://towncrier.readthedocs.io/en/stable/>`__ is used to manage
|
||||
BeeWare uses `Towncrier <https://towncrier.readthedocs.io/en/stable/>`__ to manage
|
||||
change notes.
|
||||
|
||||
A change note file should be created in the ``changes`` directory and named
|
||||
|
|
@ -38,12 +41,13 @@ using this format::
|
|||
|
||||
<PR/Issue #>.<Change Type>.rst
|
||||
|
||||
For instance, a Pull Request that fixes
|
||||
GitHub Issue #42 would be named ``42.bugfix.rst``. If a Pull Request is not
|
||||
associated with a specific Issue, then the Pull Request number should be used
|
||||
instead.
|
||||
For instance, a pull request that fixes GitHub issue #42 would be named
|
||||
``42.bugfix.rst``. If a pull request is not associated with a specific issue, then the
|
||||
pull request number can be used instead. You may need to create the pull request
|
||||
*without* a change note to get a pull request number allocated, then push an update that
|
||||
includes the change note with the newly allocated pull request number.
|
||||
|
||||
All Change Types:
|
||||
The change types for the change note should be one of the following:
|
||||
|
||||
* ``feature``
|
||||
* ``bugfix``
|
||||
|
|
@ -51,17 +55,35 @@ All Change Types:
|
|||
* ``removal``
|
||||
* ``misc``
|
||||
|
||||
The ``misc`` type is reserved for changes that do not affect users; therefore,
|
||||
they do not need to be made aware of the change for a Release. For instance,
|
||||
fixing a CI issue.
|
||||
The ``misc`` type is reserved for changes that do not affect users, and don't need to be
|
||||
noted in the release notes. Minor typographical fixes in documentation, updates to CI
|
||||
configuration, and bug fixes for features that haven't yet been formally released are
|
||||
examples of features that would be described using ``misc`` markers.
|
||||
|
||||
A change note should be a single line of text, providing a high level summary of the
|
||||
change from the perspective of the user, not a deep technical description or
|
||||
implementation detail. It is distinct from a commit message. A commit message describes
|
||||
what has been done so that future developers can follow the reasoning for a change. A
|
||||
change note is a "user facing" description, described in terms of the new capability
|
||||
that is available as a result of change. It may help to think of the change note as a
|
||||
press release announcing the change, rather than a commit description.
|
||||
|
||||
For example, if you fix a bug caused by date handling, the commit message or pull
|
||||
request description might read:
|
||||
|
||||
Added a MM-DD-YYYY format validator to the DateWidget validation chain.
|
||||
|
||||
This describes the change that was made to the implementation - detail that will be
|
||||
helpful to the person reviewing the code. However, the corresponding change note might
|
||||
read something like:
|
||||
|
||||
Date widgets can now accept dates in US format.
|
||||
|
||||
This describes the functional change as it will be experienced by end users. A user can
|
||||
read this description without needing to know anything about the implementation.
|
||||
|
||||
Code style
|
||||
---------------
|
||||
|
||||
Please follow these coding standards when writing code for inclusion in BeeWare
|
||||
projects. Unless otherwise specified, follow :pep:`8` (with careful attention
|
||||
paid to `Section 2
|
||||
<https://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds>`__).
|
||||
-----------
|
||||
|
||||
BeeWare's projects use `Pre-commit <https://pre-commit.com/>`__ to automate
|
||||
code style adherence. These checks are defined in the
|
||||
|
|
@ -115,29 +137,5 @@ Additional guidelines:
|
|||
def test_foo():
|
||||
"""A test docstring looks like this (#123456)."""
|
||||
|
||||
Sign your work
|
||||
---------------
|
||||
|
||||
Before we can merge your contribution into BeeWare, you need to give us
|
||||
permission to do so. Since you're an author of a creative work (a piece of
|
||||
code, or some documentation), you automatically own the copyright for that
|
||||
work. BeeWare can't legally use that contribution unless you give us
|
||||
permission to do so.
|
||||
|
||||
The BeeWare project uses a mechanism known as a `Developer Certificate of Origin
|
||||
(DCO) </contributing/how/dco/>`__ to manage this process. The DCO is a legally
|
||||
binding statement that asserts that you are the creator of your contribution,
|
||||
and that you wish to allow BeeWare to use your work.
|
||||
|
||||
To indicate that you agree to the terms of the DCO, you just add a line to
|
||||
every git commit message::
|
||||
|
||||
Signed-off-by: Joe Smith <joe.smith@email.com>
|
||||
|
||||
If you set your ``user.name`` and ``user.email`` as part of your git
|
||||
configuration, you can sign your commit automatically with ``git commit -s``.
|
||||
|
||||
If you have more questions about Developer Certificates of Origin, why they are
|
||||
required, what they mean, and how to configure your system to use them, see
|
||||
`The Beginners Guide to DCOs </contributing/how/dco/>`__, or `get in touch with
|
||||
the core team </community/team>`__.
|
||||
* Unless otherwise specified, follow :pep:`8` (with careful attention paid to `Section 2
|
||||
<https://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds>`__).
|
||||
|
|
|
|||
|
|
@ -9,9 +9,3 @@ Du willst mithelfen, die Inhalte dieser Website zu übersetzen oder zu aktualisi
|
|||
Diese Seiten basieren hauptsächlich auf `Lektor-Dateien (.lr) <https://www.getlektor.com/docs/content/>`__ und `.ini Data Bags <https://www.getlektor.com/docs/content/databags/>`__.
|
||||
Um eine Seite zu übersetzen, wähle die entsprechende Sprache unten aus, öffne eine Seite und klick dann auf dieser Seite oben rechts auf "Translate on GitHub".
|
||||
Um Data Bags zu übersetzen, `öffne eine .ini-Datei <https://github.com/beeware/beeware.github.io/tree/lektor/databags>`__ und erstelle oder bearbeite den Abschnitt für die entsprechende Sprache (z. B. [de] für Deutsch).
|
||||
|
||||
Einige Seiten dieser Website sind aktuell in den folgenden Sprachen verfügbar:
|
||||
|
||||
|
||||
---
|
||||
_template: translations.html
|
||||
|
|
|
|||
|
|
@ -1,10 +1,7 @@
|
|||
_template: translations.html
|
||||
---
|
||||
body:
|
||||
|
||||
Ayuda a traducir el contenido del sitio web!
|
||||
|
||||
Algunas secciones del sitio web se encuentran disponibles en los siguientes idiomas:
|
||||
---
|
||||
title: Traducciones
|
||||
---
|
||||
|
|
|
|||
|
|
@ -7,13 +7,7 @@ body:
|
|||
Quer ajudar a traduzir ou atualizar o conteúdo deste site?
|
||||
|
||||
A maior parte do conteúdo destas página encontra-se em `arquivos Lektor (.lr) <https://www.getlektor.com/docs/content/>`__
|
||||
e `databags .ini <https://www.getlektor.com/docs/content/databags/>`. Para traduzir uma página, escolha um idioma abaixo,
|
||||
e `databags .ini <https://www.getlektor.com/docs/content/databags/>`__. Para traduzir uma página, escolha um idioma abaixo,
|
||||
abra uma página e clique em "Editar no GitHub" (no canto superior direito da página). Para traduzir os databags,
|
||||
`abra um arquivo .ini <https://github.com/beeware/beeware.github.io/tree/lektor/databags>` e crie ou edite a seção
|
||||
`abra um arquivo .ini <https://github.com/beeware/beeware.github.io/tree/lektor/databags>`__ e crie ou edite a seção
|
||||
para o idioma escolhido (e.g., [pt] para português).
|
||||
|
||||
Algumas partes deste site estão no momento disponíveis nos seguintes idiomas:
|
||||
|
||||
|
||||
---
|
||||
_template: translations.html
|
||||
|
|
|
|||
|
|
@ -4,17 +4,26 @@ title: Translations
|
|||
---
|
||||
body:
|
||||
|
||||
This website
|
||||
-------------
|
||||
|
||||
Want to help translate or update the content of this website?
|
||||
|
||||
The contents of these pages are mostly written in `Lektor (.lr) files
|
||||
<https://www.getlektor.com/docs/content/>`__ and `.ini databags
|
||||
<https://www.getlektor.com/docs/content/databags/>`. To translate a page,
|
||||
select a language below, open a page then click "Edit on GitHub" (on the
|
||||
top-right corner of that page). To translate the databags, `open a .ini file
|
||||
<https://github.com/beeware/beeware.github.io/tree/lektor/databags>` and create
|
||||
or edit the section for the specified language (e.g., [pt] for Portuguese).
|
||||
<https://www.getlektor.com/docs/content/databags/>`__. To translate a page, select a
|
||||
language below, open a page then click "Edit on GitHub" (on the top-right corner of that
|
||||
page). To translate the databags, `open a .ini file
|
||||
<https://github.com/beeware/beeware.github.io/tree/lektor/databags>`__ and create or
|
||||
edit the section for the specified language (e.g., ``[pt]`` for Portuguese).
|
||||
|
||||
Some pages of this website are currently available in the following languages:
|
||||
The BeeWare Tutorial
|
||||
---------------------
|
||||
|
||||
---
|
||||
_template: translations.html
|
||||
We also maintain translations for the `BeeWare tutorial <https://docs.beeware.org>`__.
|
||||
These translations are managed using `Weblate
|
||||
<https://hosted.weblate.org/projects/beeware/>`__, a web interface for managing
|
||||
translations. If you'd like to contribute to these translations, create an account on
|
||||
Weblate, then join the ``#translations`` channel on `Discord
|
||||
<https://beeware.org/bee/chat/>`__, and tell us your account username. We'll add you
|
||||
to the translation team and you can get started!
|
||||
|
|
|
|||
Loading…
Reference in a new issue