Service Agreements issueshttps://gitlab.archlinux.org/archlinux/service-agreements/-/issues2021-08-22T11:06:33Zhttps://gitlab.archlinux.org/archlinux/service-agreements/-/issues/2Publish these documents to GitLab Pages for nicer rendering and better urls2021-08-22T11:06:33ZSven-Hendrik Haasesvenstaro@archlinux.orgPublish these documents to GitLab Pages for nicer rendering and better urlsIt might be nice to eventually publish these documents to terms.archlinux.org (or similar) as it'll make URLs nicer and it'll also probably improve rendering.It might be nice to eventually publish these documents to terms.archlinux.org (or similar) as it'll make URLs nicer and it'll also probably improve rendering.https://gitlab.archlinux.org/archlinux/service-agreements/-/issues/3Polish Code of Conduct2021-07-16T17:03:04ZDavid RungePolish Code of ConductBefore publishing our Terms of Services it is a good idea to polish and potentially also shorten (where appropriate) our Code of Conduct.
A (non-exhaustive) list of various CoCs of different projects and distributions, that we may take ...Before publishing our Terms of Services it is a good idea to polish and potentially also shorten (where appropriate) our Code of Conduct.
A (non-exhaustive) list of various CoCs of different projects and distributions, that we may take inspiration from:
- https://berlincodeofconduct.org/
- https://www.debian.org/code_of_conduct
- https://docs.fedoraproject.org/en-US/project/code-of-conduct/https://gitlab.archlinux.org/archlinux/service-agreements/-/issues/4Inconsistent use of title case and sentence case2023-06-24T05:54:13Znl6720Inconsistent use of title case and sentence caseThe code of conduct and privacy policy have their origins in the wiki, so in the title and section headings they (for the most part) use [sentence case](https://en.wikipedia.org/wiki/Sentence_case) per https://wiki.archlinux.org/title/He...The code of conduct and privacy policy have their origins in the wiki, so in the title and section headings they (for the most part) use [sentence case](https://en.wikipedia.org/wiki/Sentence_case) per https://wiki.archlinux.org/title/Help:Style#Title and https://wiki.archlinux.org/title/Help:Style#Section_headings.
The terms of service, on the other hand, uses title case.
IMO all the documents should have a consistent style and use sentence case.https://gitlab.archlinux.org/archlinux/service-agreements/-/issues/5Move the trademark policy from the wiki to this repo2023-08-09T21:27:02ZJakub KlinkovskýMove the trademark policy from the wiki to this repoThe current trademark policy is located in the wiki: https://wiki.archlinux.org/title/DeveloperWiki:TrademarkPolicy
Since the code of conduct and the privacy policy were moved here, it would make sense to move the trademark policy as we...The current trademark policy is located in the wiki: https://wiki.archlinux.org/title/DeveloperWiki:TrademarkPolicy
Since the code of conduct and the privacy policy were moved here, it would make sense to move the trademark policy as well. ([Original discussion](https://wiki.archlinux.org/title/DeveloperWiki_talk:TrademarkPolicy#Move_to_GitLab)) The [front page](https://terms.archlinux.org/) even links to the trademark policy as a separate document.
One issue that comes to mind is that the trademark policy is not a "service agreement", it won't be shown to users upon registration via Keycloak, which was the original purpose of this repo. But the descriptions of the project (which seem to define its scope) are already inconsistent, the published documents at https://terms.archlinux.org/ call it "Arch Linux Terms" or "Arch Linux legal documentation". The issue can be solved by defining the scope of the repo properly.https://gitlab.archlinux.org/archlinux/service-agreements/-/issues/6Expand contribution guidelines2021-09-18T06:46:20ZJakub KlinkovskýExpand contribution guidelinesThe README has a section on [changing these documents](https://gitlab.archlinux.org/archlinux/service-agreements/-/blob/master/README.md#changing-these-documents), but there are some issues:
- The third point ("Announce the MR on arch-d...The README has a section on [changing these documents](https://gitlab.archlinux.org/archlinux/service-agreements/-/blob/master/README.md#changing-these-documents), but there are some issues:
- The third point ("Announce the MR on arch-dev-public.") sounds like merge requests are not welcome from people who can't post to arch-dev-public (this includes even some team members – staff).
- It also seems that the rule has not been enforced even once since its addition in https://gitlab.archlinux.org/archlinux/service-agreements/-/commit/b861e2854d41e138c13d3d7ce23bc7fb65873110 on May 31.
- The fifth point states: "If the lawyer has some comments, we'll apply them without further discussion." I think there should still be some room for discussion, otherwise the lawyer could dictate us whatever they want. Or those who communicate with the lawyer (if the communication is not made transparent).
- The approval process for merge requests is not defined. The default "1 or 2 approvals from maintainers are enough" that is used in other _software_ projects is not suitable for legally binding documents.
- We should also add a clear definition of the group of people who can approve. Although it will be likely visible on Gitlab/Keycloak, it deserves a definition in the text.
- How do we ensure that enough people (ideally all team members) are aware of the proposed changes and pending approvals? Note that this issue includes also new team members.
- The third point attempts to solve this with announcements to arch-dev-public, but it has the aforementioned issue. And we still don't require, nor encourage, all team members to subscribe to the list. Also the announcements are not automated, which leaves space for forgetting and highers the bar for contributions.
- As an alternative, we can strive for a pro-active approach where people interested in following the changes and participating in the discussion (i.e. reviewing and approving) enable notifications for this project on Gitlab. But we'd still need to encourage people to do that, otherwise the result can be close to the "1 or 2 approvals from maintainers are enough".
Finally, would it make sense to move the guidelines to CONTRIBUTING.md? Could be still referenced from the README as well as from issue templates.https://gitlab.archlinux.org/archlinux/service-agreements/-/issues/7Consider deployment that is gate kept by a tag2023-08-12T18:20:42ZDavid RungeConsider deployment that is gate kept by a tagCurrently the workflow seems to be to ensure in reviews that changes to the terms are not those kind of changes that require an announcement (e.g. due to wording changes to the terms, or more substantial changes).
With a deployment meth...Currently the workflow seems to be to ensure in reviews that changes to the terms are not those kind of changes that require an announcement (e.g. due to wording changes to the terms, or more substantial changes).
With a deployment method based on tags, e.g. using calver (such as `20230810`), we would minimize our trouble in regards to announce-worthy changes and figuring out "what the current version is".
I propose automatically deploying HEAD of the default branch not to https://terms.archlinux.org, but to some preliminary subdomain (e.g. https://staging.terms.archlinux.org or some such). Only tagged versions of the terms repository are deployed to https://terms.archlinux.org
This has the following benefits:
* we know (and also the user knows) exactly which version we have deployed (due to calver)
* we can diff very easily between HEAD and latest tag (and also mention this in an announcement mail to show to the user what the actual diff between the soon-to-be and current version of the terms is)
* we can ensure more easily to not deploy noteworthy changes by accident (because we can diff more specifically). a tag can therefore be seen as a form of quality gate
cc @svenstaro @anthraxxhttps://gitlab.archlinux.org/archlinux/service-agreements/-/issues/8Licensing for the ArchLinux repositories2023-11-24T17:46:02ZBug migration userLicensing for the ArchLinux repositories| Task Info (Flyspray) | |
|--------------------------|-----------------------------------------------------------------------------------|
| <small>Op...| Task Info (Flyspray) | |
|--------------------------|-----------------------------------------------------------------------------------|
| <small>Opened By</small> | <small>[Alexandru Stan (amstan)](https://bugs.archlinux.org/user/12628)</small> |
| <small>Task ID</small> | <small>[44893](https://bugs.archlinux.org/task/44893)</small> |
| <small>Type</small> | <small>Bug Report</small> |
| <small>Project</small> | <small>Arch Linux</small> |
| <small>Category</small> | <small>Arch Projects</small> |
| <small>Version</small> | <small>None</small> |
| <small>OS</small> | <small>All</small> |
| <small>Opened</small> | <small>2015-05-07 21:36:31 UTC</small> |
| <small>Status</small> | <small>Assigned</small> |
| <small>Assignee</small> | <small>[Levente Polyak (anthraxx)](https://bugs.archlinux.org/user/17958)</small> |
### Details
A few days ago I wished to contribute to the Arch Linux ARM project, which is a downstream project, but all of this is applicable to Arch proper first (and it probably needs to be solved before Arch Linux ARM can take steps to fix this).
This contribution was sparked because I am a ChromeOS developer for Google. I made that patch(adding a new PKGBUILD) as a Google employee with Google hardware (it wouldn't make sense for me to do it on my personal time). As a result my employer has to approve any open source releases/patches that I write.
I had a new PKGBUILD ready for Arch Linux ARM, but my employer refused to approve it. As far as they are concerned the PKGBUILDs are not licensed under an open source license.
The situation is that even though the patches in every folder and the packages themselves are licensed under the respective licenses (the license=('') line in the pkgbuilds), the PKGBUILD themselves and the install scripts have no license.
I know some of you consider this to not be a big deal (why would anyone get upset over copying a thing that a project's documentation says you should do), but this essentially prevents me from contributing things related to my job to Arch Linux or Arch Linux ARM.
Is there some way we could attach a license to all these files?https://gitlab.archlinux.org/archlinux/service-agreements/-/issues/9Make wasting time and generating more moderation work a bannable offence2024-03-20T13:05:31Znl6720Make wasting time and generating more moderation work a bannable offenceSome while ago I read https://news.ycombinator.com/item?id=37502258#37506147:
> I've been there. On a Discord I used to moderate, there were a few people like that who did not really break any rule, or not in an egregious enough manner t...Some while ago I read https://news.ycombinator.com/item?id=37502258#37506147:
> I've been there. On a Discord I used to moderate, there were a few people like that who did not really break any rule, or not in an egregious enough manner to deserve a ban individually
>
> A rule was made for that situation: "**If the effort and/or stress associated with moderating you regarding rules or general behavior becomes too much of an issue, we will remove you from the server.**".
>
> That rule has been used a few times since its implementation.
I think we should add a rule like that to our code of conduct.