From 57f51fa24f06e0efbd34761bfb9affd4045e8aad Mon Sep 17 00:00:00 2001 From: DominikaK Date: Fri, 10 Jun 2022 07:57:41 +0200 Subject: [PATCH] Contributing section cleanup --- docs/community_resources/code.md | 41 ----- docs/community_resources/contributing.md | 17 -- .../development_guidelines.md | 149 ------------------ docs/community_resources/documentation.md | 74 --------- docs/community_resources/package_structure.md | 3 + docs/community_resources/release_process.md | 28 +--- .../report_follow_issues.md | 54 ++----- docs/community_resources/resources.md | 18 --- docs/community_resources/translations.md | 4 - docs/guide/security_checklist.md | 2 - mkdocs.yml | 5 - 11 files changed, 17 insertions(+), 378 deletions(-) delete mode 100644 docs/community_resources/code.md delete mode 100644 docs/community_resources/contributing.md delete mode 100644 docs/community_resources/development_guidelines.md delete mode 100644 docs/community_resources/documentation.md delete mode 100644 docs/community_resources/resources.md diff --git a/docs/community_resources/code.md b/docs/community_resources/code.md deleted file mode 100644 index 73f67fa584..0000000000 --- a/docs/community_resources/code.md +++ /dev/null @@ -1,41 +0,0 @@ -# Contribute code - -If you intend to change existing or introduce new code, start with a proper explanation. -It should be placed in a public ticket. -All the rules to follow can be found in [Contribute to documentation](documentation.md) section. - -Once you are done with describing your idea, focus on the main part - sharing the actual solution. -Ibexa uses a regular git workflow, so if you are familiar with the concept, the whole procedure should be pretty straightforward. - -[[= product_name =]] is divided into meta-repositories. -The core of our system is [`ibexa/core`](https://github.com/ibexa/core) -containing an advanced Content Model and aiming to provide additional features for the MVC layer (Symfony). -On the other hand, e.g. `admin-ui` is strictly dedicated to the Admin Panel purposes. -If you want to learn more about our code structure, take a look at [our organization page on GitHub](https://github.com/ibexa) -or the list of [core bundles](../guide/bundles.md#core-packages). - -After finishing your work, fork repository which you want to contribute to. -Now you need to determine which version of the package your changes should target. -If you plan to fix something in your current project, check `composer.json` for the version of the package and pick proper branch. - -For example: you added a `try { } catch () {}` statement fixing an annoying error in `admin-ui` -and you are using version 2.5. You should aim for branch `1.5` then, as version `1.5.0` is used. - -Now you can follow the same procedure as in [Contributing through git](documentation.md#contributing-through-git). - -!!! caution "Public repositories" - - You can contribute only to the public repositories. - This means that all repositories marked as `private` are not open to contributions outside our organization. - However, you can generate a patch from your own codebase and attach it to the Customer Ticket. - That will allow our engineers to open a pull request in a private repository on your behalf. - -To become a part of the product your changes must pass our team's review. -Not all pull requests can be approved. Be prepared that some will need changes before they can be accepted. -When you respond to questions and discussion around your PR and make changes to it as needed, -you increase the chance that it will be accepted and reduce the waiting period. -Keep in mind that not every suggestion meets requirements of the product or chosen business strategy. - -**Don't hesitate to share your work** even if you don't consider yourself an experienced developer. -Our Engineers will help you meet our standards, follow good coding practices, -adapt to our solutions/code conventions and pay attention to details. diff --git a/docs/community_resources/contributing.md b/docs/community_resources/contributing.md deleted file mode 100644 index 1d634abccd..0000000000 --- a/docs/community_resources/contributing.md +++ /dev/null @@ -1,17 +0,0 @@ -# How to contribute - -Are you ready to become a part of the Ibexa Community? There are several ways in which you can contribute, from spotting and reporting bugs to committing to the documentation to discussing innovative uses on Slack to coding new bundles. - -If you're looking to contribute code, whether in a form of corrections or separate bundles with features, Ibexa OSS, [[= product_name =]]'s open-source version, lets you do this without any fuss by using GitHub. -Take a look at our [Development guidelines](development_guidelines.md) to get started. - -- [Report and follow issues](report_follow_issues.md) if you'd just like to let us know of a bug you've encountered - -- [Contribute code](code.md) if you've fixed a bug or implemented improvement/feature - -- [Contribute translations](translations.md) if you'd like to add a translation of [[= product_name =]] interface - -- [Contribute to documentation](documentation.md) if you've noticed any improvement needed in the documentation - -- Visit [Community website](http://share.ez.no) or the [eZ Community Slack team](https://ezcommunity.slack.com/) if what you're looking for is simply discussing the way you use [[= product_name =]] -  diff --git a/docs/community_resources/development_guidelines.md b/docs/community_resources/development_guidelines.md deleted file mode 100644 index b7ead27bde..0000000000 --- a/docs/community_resources/development_guidelines.md +++ /dev/null @@ -1,149 +0,0 @@ -# Development guidelines - -These are the development/coding guidelines for [[= product_name =]] kernel, they are the same if you intend to write Bundles, hack on [[= product_name =]] itself or create new functionality for or on top of [[= product_name =]]. - -Like most development guidelines these aims to improve security, maintainability, performance and readability of our software. They follow industry standards but sometimes extend them to cater specifically to our needs for [[= product_name =]] ecosystem. The next sections will cover all relevant technologies from a high level point of view. - -!!! tip "Security checklist" - - See the [Security checklist](../guide/security_checklist.md) for a list of security-related issues - you should take care of before going live with a project. - -## HTTP - -[[= product_name =]] is a web software that is reached via HTTP in most cases, out of the box in [[= product_name =]] kernel this is specifically: web (usually HTML) or REST. - -We aim to follow the [latest](http://trac.tools.ietf.org/wg/httpbis/trac/wiki#HTTP1.1Deliverables) stable HTTP specification, and industry best practice: - -- **Expose our data in a RESTful way** - - GET, HEAD, OPTIONS and TRACE methods are [safe](http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-21#section-5.2.1) (otherwise known as [nullipotent](http://en.wiktionary.org/wiki/nullipotent)), as in: should never cause changes to resources (note: things like writing a line in a log file are not considered resource changes) - - PUT and DELETE methods are [idempotent](http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-21#section-5.2.2), as in multiple identical requests should all have the same result as a single request - - GET and HEAD methods should be [cacheable](http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-21#section-5.2.3) both on client side, server-side and proxies between, as further defined in the HTTP [specification](http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-21) - - As PUT is for replacing a resource, we should use [PATCH](http://tools.ietf.org/html/rfc5789) in cases where only partial replacement is intended -- **Authenticated traffic** - - Should use HTTPS -- **Session based traffic** - - Should follow recommendations for *Authenticated traffic* - - Should use a per user session [CSRF](http://en.wikipedia.org/wiki/Cross-site_request_forgery) token on all requests using un-safe HTTP methods (POST, PUT, DELETE, PATCH, ...) - - Should expire session ID, session data and CSRF token on login, logout and session time out, except: - - On login session data from previous session ID is moved to new session ID, keeping for instance shopping basket on login - - Should avoid timing attacks by using a random amount of time for login operation - - Should never use Session ID in URI's. And this feature ("SID") must always be disabled on production servers -- **Sessions** - - Should not be used to store large amounts of data; store data in database and ID's in session if needed - - Should not store critical data: if user deletes his cookies or closes his browser session data is lost - - Should use an ID generated with enough randomness to prevent prediction or brute-force attacks -- **Cookies (especially session cookies)** - - Should never store sensitive data in cookies (only exception is session ID in session cookie) - - Should always set *Full domain* to avoid [cross-subdomain cooking](https://en.wikipedia.org/wiki/Session_fixation#Attacks_using_cross-subdomain_cookie) when on shared domain. - - Should set *HttpOnly* flag to reduce risk of attacks such as [cross-site cooking](https://en.wikipedia.org/wiki/Cross-site_cooking) and [cross-site scripting](http://en.wikipedia.org/wiki/Cross-site_scripting "Cross-site scripting") - - Should set *Secure flag* if HTTPS is used (as recommended above) - - Must never exceed 4kB -- **Headers** - - Should never include input data from user input or data from database without sanitizing it -- **Redirects** - - Should never take URL from user input (example: POST parameter), instead allow identifiers instead that are understood by the backend -- **User input** - - Should always be validated, sanitized, casted and filtered to avoid [XSS](http://en.wikipedia.org/wiki/Cross-site_scripting) and [clickjacking](http://en.wikipedia.org/wiki/Clickjacking) attacks - - Note: this includes variables in the php supervariable `$_SERVER` as well (e.g. hostname should not be trusted) -- **User file uploads** - - Should follow recommendations for "User input" to validate file name - - Should place uploaded files in a non public folder to avoid access to execute uploaded file or in case of assets white list the type - - Should be appropriately limited in size to avoid DOS attacks on disk space, CPU usage by antivirus tool etc... -- **File downloads** - - Should not rely on user provided file path for non public files, instead use a synthetic ID -- **Admin operations** - - May be placed on a different (sub)domain then the front end website to avoid session stealing across front and backend. -- **Fully support being placed behind a reverse proxy like [Varnish](https://www.varnish-cache.org/)** - -## UI - -[[= product_name =]] is often used as a web content management software, so we always strive to use the HTML/CSS/EcmaScript specifications correctly, and keep new releases up to date on new revisions of those. We furthermore always try to make sure our software gracefully degrades making sure it is useful even on older or less capable web clients (browsers), the industry terms for this approach are: - -- [Progressive enhancement](http://en.wikipedia.org/wiki/Progressive_enhancement "Progressive enhancement") -- [Unobtrusive JavaScript](http://en.wikipedia.org/wiki/Unobtrusive_JavaScript) -- [Responsive Design](http://en.wikipedia.org/wiki/Responsive_Web_Design "Responsive Web Design") - -All these terms in general recommends aiming for the minimum standard first, and enhance with additional features/styling if the client is capable of doing so. In essence this allows [[= product_name =]] to be "Mobile first" if the design allows for it, which is recommended. But [[= product_name =]] should always also be fully capable of having different sets of web presentations for different devices using one or several sets of SiteAccess matching rules for the domain, port or URI, so any kind of device detection can be used together with [[= product_name =]], making it fully possible to write for instance [WAP](http://en.wikipedia.org/wiki/Wireless_Application_Protocol) based websites and interfaces on top of [[= product_name =]]. - -### WEB Forms/Ajax - -As stated in the HTTP section, all unsafe requests to the web server should have a CSRF token to protect against attacks; this includes web forms and ajax requests that don't use the GET http method. As also stated in the HTTP section and further defined in the PHP section, User input should always be validated to avoid XSS issues. - -### HTML/Templates - -All data that comes from backend and in return comes from user input should always be escaped, in case of Twig templates this done by default, but in case of PHP templates, Ajax and other not Twig based output this must be handled manually. - - -Output escaping must be properly executed according to the desired format, eg. JavaScript vs. HTML, but also taking into account the correct character set (see e.g. output escaping fallacy when not specifying charset encoding in [htmlspecialchars](http://www.php.net/htmlspecialchars)) - -### Admin - -Admin operations that can have a severe impact on the web applications should require providing password and require it again after some time has gone, normally 10-20 minutes, on all session-based interfaces. - -## PHP - -### Public API - -The [Public PHP API](../api/public_php_api) provided in [[= product_name =]] is in most cases in charge of checking permissions to data for you, but some API's are not documented to throw `UnauthorizedException`, which means that it is the consumer of the API's who is responsible for checking permissions. - -The following example shows how this is done in the case of loading users: - -**loadUser()** - -``` php -// Get a user -$userId = (int)$params['id']; -$userService = $repository->getUserService(); -$user = $userService->loadUser( $userId ); - -// Now check that current user has access to read this user -if ( !$repository->canUser( 'content', 'read', $user ) ) -{ - // Generates message: User does not have access to 'content' 'read' with id '10' - throw new \Ibexa\Contracts\Core\Repository\Exceptions\UnauthorizedException\UnauthorizedException( 'content', 'read', [ 'id' => $userId ] ); -} -``` - -### Command line - -Output must always be escaped when displaying data from the database. - -## Data and databases - -- Values coming from variables should always be appropriately quoted or binded in SQL statements -- The SQL statements used should never be created by hand with one version per supported database, as this increases both the maintenance load and the chances for security-related problems -- Usage of temporary tables is discouraged, as their behavior is very different on different databases. Subselects should be preferred (esp. since recent mysql versions have much better support for them) -- Full table locking is discouraged - -### Sessions - -- Business logic should not depend on database connections being either persistent or not persistent -- The connection to the database should always be opened as late as possible during page execution. Ideally, to improve scalability, a web page executing no queries should not connect to the database at all (note that closing the database connection as soon as possible is a tricky problem, as we expect to support persistent database connections as well for absolute best performances) -- The same principle applies to configurations where a master/slave database setup is in use: the chance for a failure due to a database malfunction should not increase with the number of database servers at play, but actually decrease -- It is recommended to avoid as much as possible statements which alter the current session, as they slow down the application, are brittle and hard to debug. - Point in case; if a database session locks a table then is abruptly terminated, the table might stay locked for a long time - -### Transactions - -- Transactions should always be used to wrap sql statements which affect data in multiple tables: either all data changes go through or none of them -- Transactions are prone to locking issues, so the code executed within a transaction should be limited to the minimum necessary amount (ex. clearing caches should be done after the transaction is committed) -- When using transactions, always consider side effects on external system, such as on-disk storage. E.g. is a transaction relative to creating an image variation is rolled back, the corresponding file should not be left on disk -- Nested transactions are supported in the following way: - - a transaction within another one will not commit when requested, only the outermost transaction will commit - - a transaction within another one will roll back all the way to the start of the outermost transaction when requested - - as a result a transaction shall never be rolled back just as a means of cancelling its work - the side effect might be of cancelling other work which had just been done previously - -### Limitations in the SQL dialect supported - -Striving to support Mysql 5, PostgreSQL xx and Oracle 10, the following limitations apply: - -- Tables, columns and other database objects should not use names longer than 30 chars -- Varchar columns with a definition of *default "" not null* are discouraged -- For SELECTs, offset and limit have to be handled by the php layer, not hardcoded in the SQL -- Never treat a NULL varchar value as semantically different from an empty string value -- The select list of a query cannot contain the same field multiple times -- For GROUP BY statements, all fields in the group by clause should be in the select list as well -- For SELECTs, usage of the AS token is allowed in the select list, but not in the list of tables -- Do not put quotes around numeric values (use proper casting/escaping to avoid SQL injection) -  diff --git a/docs/community_resources/documentation.md b/docs/community_resources/documentation.md deleted file mode 100644 index 4bb33009b4..0000000000 --- a/docs/community_resources/documentation.md +++ /dev/null @@ -1,74 +0,0 @@ -# Contribute to documentation - -While we are doing our best to make sure our documentation fulfills all your needs, there is always place for improvement. - -This documentation is written on GitHub and generated into a static site. It is organized in branches. Each branch is a version of documentation (which in turn corresponds to a version of [[= product_name =]]). - -If you are familiar with the git workflow, you will find it easy to contribute. -Please create a Pull Request for any, even the smallest change you want to suggest. - -## Contributing through the GitHub website - -To quickly contribute a fix to a page, find the correct `*.md` file in the GitHub repository and select "Edit this file". - -Introduce your changes, at the bottom of the page provide a title and a description of what you modified and select "Propose file change". - -This will lead to a screen for creating a Pull Request. Enter a name and description for the pull request and select "Create pull request". - -Your pull request will be reviewed by the team and, when accepted, merged with the rest of the repository. -You will be notified of all activity related to the pull request by email. - -## Contributing through git - -You can also contribute to the documentation by using a regular git workflow. -If you are familiar with it, this should be quick work. - -1. Assuming that you have a GitHub account and a git command line tool installed, -fork the project and clone it into a folder: `git clone XXX .` - -1. Add your own fork as a remote: `git remote add fork
`. - -1. Checkout the branch you want to contribute to: - -``` -git checkout -git fetch origin -git rebase origin/ -``` - -!!! note "Choosing a branch" - - Always contribute to the **earliest** branch that a change applies to. - For example, if a change concerns versions v1.7 and v.1.13, make your contribution to the `v1.7` branch. - The changes will be merged forward to be included in later versions as well. - -1. Create a new local branch: `git checkout -b `. - -1. Now introduce whatever changes you wish, either modifying existing files, or creating new ones. - -1. Once you are happy with your edits, add your files to the staging area. Use `git add .` to add all changes. - -1. Commit your changes, with a short, clear description of your changes: `git commit -m "Description of commit"`. - -1. Now push your changes to your fork: `git push fork `. - -1. Finally, you can go to the project's page on GitHub and you should see a "Compare and pull request" button. Activate it, write a description and select "Create pull request". If your contribution solves a JIRA issues, start the pull request's name with the issue number. Now you can wait for your changes to be reviewed and merged. - -## Contributing outside git and GitHub - -- **Create a JIRA issue.** You can also report any omissions or inaccuracies you find by creating a JIRA issue. See [Report and follow issues](report_follow_issues.md) on how to do this. Remember to add the "Documentation" component to your issue to make sure we don't lose track of it -- **Visit Slack.** The `\#documentation-contrib` channel on [eZ Community Slack team](http://ez-community-on-slack.herokuapp.com) is the place to drop your comments, suggestions, or proposals for things you'd like to see covered in documentation. (You can use the link to get an auto-invite to Slack) -- **Contact the Doc Team.** If you'd like to add to any part of the documentation, you can also contact the Doc Team directly at - -## Writing guidelines - -- Write in (GitHub-flavored) Markdown -- Try to keep lines no longer than 120 characters. If possible, break lines in logical places, for example at sentence end. -- Use simple language -- Call the user "you" (not "the user", "we", etc.). -Use gender-neutral language: the visitor has *their* account, not *his*, *her*, *his/her*, etc. - -**Do not be discouraged** if you are not a native speaker of English and/or are not sure about your style. -Our team will proofread your contribution and make sure any problems are fixed. Any edits we do are not intended to be a criticism of your work. -We may simply modify the language of your contributions according to our style guide, -to make sure the terminology is consistent throughout the docs, and so on. diff --git a/docs/community_resources/package_structure.md b/docs/community_resources/package_structure.md index ab61898bf5..3fc4b73f4b 100644 --- a/docs/community_resources/package_structure.md +++ b/docs/community_resources/package_structure.md @@ -1,5 +1,8 @@ # Package and bundle structure and namespaces +If you wish to contribute to [[= product_name =]] development, +you need to adhere to the package and bundle structure and namespace standards. + The following conventions apply to contributions to Ibexa core code, not to third party packages. !!! note diff --git a/docs/community_resources/release_process.md b/docs/community_resources/release_process.md index e18862b332..03a6ae53d3 100644 --- a/docs/community_resources/release_process.md +++ b/docs/community_resources/release_process.md @@ -21,8 +21,6 @@ We manage the release of [[= product_name =]] using an agile iterative process a FT releases are tailored for those who want to stay up-to-date with newest functionalities, while LTS releases are suitable for highly stable enterprise rollouts. -We usually release [[= product_name =]] four times a year following the seasons (winter, spring, summer and fall). This usually includes one LTS release and three FT releases. - ## Versioning conventions All [[= product_name =]] editions use [semantic versioning](http://semver.org/). @@ -39,31 +37,7 @@ Distribution files of our three editions are as follows: - for [[= product_name_exp =]]: ibexa-experience-vX.Y.Z.tgz - for [[= product_name_com =]]: ibexa-commerce-vX.Y.Z.tgz -## Support lifecycle - -Our software products are continuously evolving. -With each release we strive to release stable products with cutting-edge technology. -This means there is need for software maintenance services to provide bug fixes and adjustments. -As our products constantly provide new features and possibilities, our documentation and user forums may not always be able to provide an answer to all questions that may arise. - -That is why our support and consulting professional services teams are available to assist -as part of an [[= product_name =]] subscription or as part of a specific statement of work. -[Contact our Sales team](https://www.ibexa.co/about-ibexa/contact-us) for more information. - -Over time, existing product versions mature and new versions become the center of attention for customers looking for the latest features. -We adapt to this continuous evolution by phasing out services for the old versions while commencing services for the new ones. -This means that our support and maintenance services specific to each release -are only available from a given start date until an end date. +Our support and maintenance services specific to each release are only available from a given start date until an end date. The time in between the start and end dates is what we call the product's **Service Life**. You can find the specific dates of service life for each release on our [support portal service life page](https://support.ibexa.co/Public/Service-Life). - -## Roadmap - -[Our roadmap](https://portal.productboard.com/ibexa) is updated continuously following our iterative development methodology (our own adaptation and combination of Scrum and Kanban). -Our agile boards offer a clear view of the ongoing and upcoming development and are open to the public. -Progress is based on the prioritized stories from a living backlog into phases of specification and design, development and documentation, and QA. -The final phase of development includes a dedicated period of Certification and Quality Assurance, -which ensures our ability to deliver a stable first version of the professionally supported software. - -If you want to know more, please contact productmanagement@ibexa.co. diff --git a/docs/community_resources/report_follow_issues.md b/docs/community_resources/report_follow_issues.md index d3961866cf..f5e8d3d122 100644 --- a/docs/community_resources/report_follow_issues.md +++ b/docs/community_resources/report_follow_issues.md @@ -1,63 +1,35 @@ # Report and follow issues -The development of Ibexa projects is organized using a bugtracker. It can be found here: . Its role is to centralize references to all improvements, bug fixes and documentation being added to Ibexa projects. - -The first thing you should do in order to be able to get involved and have feedback on what is happening on Ibexa projects is to create a JIRA account. - -**Note:** The term "issue" is used to refer to a bugtracker item regardless of its type (bug, improvement, story, etc.) - -!!! caution "Security issues" - - If you discover a security issue, please do not report it using regular channels, but instead take a look at [Security section](../guide/reporting_issues.md). +[[= product_name =]] uses [JIRA](https://issues.ibexa.co) to track product development, improvements, and bugs. ## Finding an existing issue -When you have a great idea or if you have found a bug, you may want to create a new issue to let everyone know about it. Before doing that, you should make sure no one has made a similar report before. - -In order to do that, you should use the search page available in the top menu (under **Issues/Search for issues**) or the search box in the top right corner. Using filters and keywords you should be able to search and maybe find an issue to update instead of creating a new one. - -## Improving existing issues - -Existing issues need to be monitored, sorted and updated in order to be processed in the best way possible. - -In case of bugs, trying to reproduce them, in order to confirm that they are (still) valid, is a great help for developers who will later troubleshoot and fix them. By doing that you can also provide extra information, if needed, such as: - -- Extra steps to reproduce -- Context/environment-specific information -- Links to duplicate or related issues - -In case of improvements, you can add extra use cases and spot behaviors that might be tricky or misleading. - -## Following an issue - -Every issue has a "Start watching this issue" link. It lets you receive notifications each time the issue is updated. - -This way you can get and provide feedback during the issue's life. You are also informed about ongoing development regarding the issue and can try out patches before they are integrated into the product. +Before you create a new bug report or an improvement suggestion, +search the JIRA project for similar reported issues. +If you find any, update them with your comment or additional information instead of creating a new one. ## Reporting an issue -!!! note "Issues in [[= product_name_exp =]] [[% include 'snippets/experience_badge.md' %]] [[% include 'snippets/commerce_badge.md' %]]" +!!! caution "Security issues" + + If you discover a security issue, please do not report it using regular channels, but instead take a look at [Security section](../guide/reporting_issues.md). - If you have an Enterprise subscription, report your issues through the [support portal](https://support.ez.no) - instead of JIRA. This ensures the issue can be quickly prioritized according to its impact. +If you have an [[= product_name =]] subscription, report your issues through the [support portal](https://support.ibexa.co) instead of JIRA. +This ensures the issue can be quickly prioritized according to its impact. -If you cannot find an issue matching what you are about to report using the search page, you can create a new one. -Click **Create** at the top of the bugtracker window and fill in the form: +If you cannot find an existing ticket matching what your issue, you can create a new one. +Click **Create** at the top of the bugtracker window and fill in the following fields: ||| |------|------| -|**Project**|Select **eZ Publish/Platform** if your issue affects platform as a standalone project, or **eZ Platform Enterprise Edition** if it is needed in order to reproduce the issue.| +|**Project**|Select **Ibexa IBX**.| |**Issue type**|Choose **Bug** or **Improvement** depending on what you are reporting, do not use other issue types (they are for internal use only).| |**Summary**|Write a short sentence describing what you are reporting.| -|**Security level**|Select security if you are reporting a security issue. It will make your issue visible only to you and the core dev team until it is fixed and distributed.| |**Priority**|Select the priority you consider the issue to be. Please try to keep a cool head while selecting it. A 1 pixel alignment bug is not a "blocker".| |**Component/s**|This is important, as it will make your issue appear on the radar (dashboards, filters) of people dealing with various parts of Ibexa projects.| |**Affect version/s**|Add the versions of the application you experienced the issue on.| -|**Fix version/s**|Leave blank.| |**Assignee**|Leave blank, unless you are willing to work on the issue yourself.| |**Reporter**|Leave as is (yourself).| |**Environment**|Enter specific information regarding your environment that could be relevant in the context of the issues.| |**Description**|This is the most important part of the issue report. In case of a bug, it **must** contain explicit steps to reproduce your issue. Anybody should be able to reproduce it at first try. In case of an improvement, it needs to contain use cases and detailed information regarding the expected behavior.| -|**Labels**|Leave blank.| -|**Epic Link**|Leave blank.| -|**Sprint**|Leave blank.| +|**Product**|Select which flavor of [[= product_name =]] the issue concerns.| diff --git a/docs/community_resources/resources.md b/docs/community_resources/resources.md deleted file mode 100644 index 7ab8f42e83..0000000000 --- a/docs/community_resources/resources.md +++ /dev/null @@ -1,18 +0,0 @@ -# Resources - -In the course of its development [[= product_name =]] has been deeply rooted in its community. This remains true, with many invaluable contributions by dedicated community members who play a key role in the continuous development of [[= product_name =]].  - -eZ partners, customers, independent developers, designers, and digital content enthusiasts can contribute to important web projects, influence the [eZ roadmap](https://doc.ez.no/display/MAIN/eZ+Platform+Release+Process+and+Roadmap), and ensure the platform stays on top of market trends and organizations' needs. - -This section provides information about the benefits you can draw from the community and about how you can contribute to [[= product_name =]]'s development yourself. - -- ** - The Developer Hub**, - the best place to start for all things [[= product_name =]]! - - Downloads - - Developer Blog -- **[eZ Community Slack team](http://ez-community-on-slack.herokuapp.com/)**, the place to discuss [[= product_name =]] with Community members, developers, and other like-minded individuals. -- **[ibexa.co](http://ibexa.co) - The corporate website for Ibexa**, - here you can find overviews of the products, contact information, and a wealth of additional [resources](http://ez.no/Resources/) such as use cases, webinars and e-books. - - [ibexa Blog](https://www.ibexa.co/blog) - Current insights from the eZ world. - - [Partner Portal](https://partners.ibexa.co) - For eZ Business Partners with a knowledge and sales resource repository. - -  - The Legacy (ez Publish) Portal diff --git a/docs/community_resources/translations.md b/docs/community_resources/translations.md index 2d4134d172..02aaf8be42 100644 --- a/docs/community_resources/translations.md +++ b/docs/community_resources/translations.md @@ -15,7 +15,3 @@ Visit [[[= product_name =]]'s Crowdin page](https://crowdin.com/project/ibexa-dx If the language you want to translate to is not available, you can ask for it to be added in the [Crowdin discussion forum for [[= product_name =]]](https://crowdin.com/project/ibexa-dxp/discussions). Crowdin then automatically creates a GitHub PR and the translations are updated in the product. - -## Full translation workflow - -You can read a full description of how new translations are prepared and distributed in [the documentation of GitHub](https://github.com/ibexa/i18n/blob/main/README.md). diff --git a/docs/guide/security_checklist.md b/docs/guide/security_checklist.md index b01abdbbd9..9b47399807 100644 --- a/docs/guide/security_checklist.md +++ b/docs/guide/security_checklist.md @@ -9,8 +9,6 @@ make sure that your setup is secure. released via [your service portal,](https://support.ibexa.co/) or via [Security advisories](https://developers.ibexa.co/security-advisories) if you're not a subscriber. - Please also refer to [development guidelines](../community_resources/development_guidelines.md) during development. - ## Symfony ### `APP_SECRET` diff --git a/mkdocs.yml b/mkdocs.yml index da745c0725..811b69af90 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -484,17 +484,12 @@ nav: - 'Multi-file upload': 'extending/extending_multifile_upload.md' - 'Sub-items list': 'extending/extending_subitems_list.md' - Resources and community: - - 'Resources': 'community_resources/resources.md' - 'Release process and roadmap': 'community_resources/release_process.md' - 'Support and maintenance FAQ': 'community_resources/support_maintenance_faq.md' - 'Ibexa DXP PhpStorm plugin': 'community_resources/phpstorm_plugin.md' - Contributing: - - 'How to contribute': 'community_resources/contributing.md' - 'Report and follow issues': 'community_resources/report_follow_issues.md' - - 'Contribute code': 'community_resources/code.md' - - 'Development guidelines': 'community_resources/development_guidelines.md' - 'Contribute translations': 'community_resources/translations.md' - - 'Contribute to documentation': 'community_resources/documentation.md' - 'Package structure': 'community_resources/package_structure.md' - Update and migration: - 'Update Ibexa DXP': 'updating/update_ibexa_dxp.md'