Sahana Eden Wiki - Recent changes [en]

Guidelines:Quality

Dominic — Thu, 29 Oct 2026 13:48:56 GMT

Consistent

← Older revision		Revision as of 13:48, 29 October 2026
Line 90:		Line 90:
	* The solution interoperates appropriately and correctly with other system components		* The solution interoperates appropriately and correctly with other system components
	* The solution applies the application's global design and style guidelines (both for code and interfaces)		* The solution applies the application's global design and style guidelines (both for code and interfaces)
	* Where appropriate or required, the solution complies with specified standards (see [#Standards Standards])		* Where appropriate or required, the solution complies with specified standards (see [[#Standards\| Standards]])

	=== Robust ===		=== Robust ===

Guidelines:Index

Dominic — Thu, 29 Oct 2026 13:39:29 GMT

Contributor Guidelines

← Older revision		Revision as of 13:39, 29 October 2026
Line 7:		Line 7:
	* [[Guidelines:ContributorWorkflow\|Git Workflow for Code Contributions]]		* [[Guidelines:ContributorWorkflow\|Git Workflow for Code Contributions]]
	* [[Guidelines:CodingStyle\|Coding Conventions]]		* [[Guidelines:CodingStyle\|Coding Conventions]]
			* [[Guidelines:Quality\|Solution Quality Evaluation Guideline]]
	* [[Guidelines:AI\|Guideline for Responsible AI Contributions]]		* [[Guidelines:AI\|Guideline for Responsible AI Contributions]]

Guidelines:Quality

Dominic — Thu, 29 Oct 2026 13:37:35 GMT

General Quality Requirements

Show changes

Guidelines:Quality

Dominic — Thu, 29 Oct 2026 13:27:49 GMT

Created page with "= Solution Quality Evaluation Guideline = == General Quality Requirements == The general quality requirements are defined here as attributes of the solution that is to be evaluated ("The solution must be ..."). These attributes are grouped in four quality "levels" - a higher level representing a higher quality standard. Projects can refer to these levels to define minimum quality goals, to prioritize certain quality aspects vs. other requirements, or to define an it..."

New page

= Solution Quality Evaluation Guideline =

== General Quality Requirements ==

The general quality requirements are defined here as attributes of the solution that is to be evaluated ("The solution must be ...").

These attributes are grouped in four quality "levels" - a higher level representing a higher quality standard.

Projects can refer to these levels to define minimum quality goals, to prioritize certain quality aspects vs. other requirements, or to define an iterative approach of continuous quality improvement.

In order to pass a level, all criteria of this level and all previous levels must be met.

{| class="wikitable" style="margin:auto"
|+ Quality Levels
|-
! Level !! Priority (MoSCoW) !! Key Attributes !! Description
|-
||0 - '''Experimental'''||-||-||any solution that does not (yet) meet all criteria of level 1||
|-
||1 - '''Minimal'''||Must||[[#Valid| valid]], [[#Correct| correct]], [[#Safe| safe]]||minimum standard for any solution||
|-
||2 - '''Appropriate'''||Should||[[#Usable| usable]], [[#Maintainable| maintainable]], [[#Secure| secure]]||minimum standard for production use||
|-
||3 - '''Good'''||Can||[[#Consistent| consistent]], [[#Robust| robust]], [[#Configurable| configurable]]||long-term development goals||
|-
||4 - '''Optimal'''||Want||[[#Efficient| efficient]], [[#Scalable| scalable]], [[#Interoperable| interoperable]]||optimization and enhancement goals||
|}
=== Level 1: Minimal ===

==== Valid ====

''"Writing the right code"''

* The specified solution solves the targeted problem and meets the minimum functional requirements
* The required input data are available in the target scenario
* The user actions required to apply and/or use the solution or its responses are ''possible'' in the target scenario
* All dependencies of the feature set are resolvable, and hardware and infrastructure requirements can be met in the target scenario

==== Correct ====

''"Writing the code right"''

* Processing does not fail for any valid input data or user action.
* All responses are correct for the respective input data or user actions according to the specification

==== Safe ====

* The solution does not break other functionality of the application (except for functionality it replaces or supersedes)
* All processing always ends with a valid database status regardless whether it succeeds or fails
* All failed processes are effectively removed from the system and their transactions properly rolled back
* The solution effectively prevents uncontrolled indefinite object or process proliferation
* The solution always returns to a defined system status after a failure so that the application remains accessible

=== Level 2: Appropriate ===

==== Usable ====

* The solution ''can'' be used by the intended user group in the target scenario, i.e. the users can:
** discover and access the features
** understand and perform the required user actions
** understand and control the consequences of actions
** understand and provide the required type, quality and format of input data
** discover and access the results, and apply them to achieve their goals

* Usability criteria apply analogously for back-end libraries and tools with developers in the role of the user

==== Maintainable ====

* All critical dependencies are obvious at their starting point
* All non-critical dependencies have meaningful fallbacks
* Processing failures produce useful and accessible feedback about the reasons
* The design of the solution does not obstruct diagnostics of defects
* The code is structured in a way that the processing flow can easily be determined from it

==== Secure ====

* The solution applies all relevant system configurations for authentication, authorization and accounting (AAA) appropriately and correctly.
* The solution does not allow the user to perform actions or initiate processes beyond the intended functionality.

=== Level 3: Good ===

==== Consistent ====

''"Maintaining Conceptual Integrity across the Application and beyond"''

* The solution applies the application framework appropriately and correctly
* The data structures defined in the solution are consistent with the global application data model
* The solution interoperates appropriately and correctly with other system components
* The solution applies the application's global design and style guidelines (both for code and interfaces)
* Where appropriate or required, the solution complies with specified standards (see [#Standards Standards])

==== Robust ====

* The solution delivers consistent behavior, results and performance for all valid configurations
* The solution handles invalid input data, unexpected user actions and irregular system conditions appropriately and consistently for all valid configurations
* The solution detects invalid configurations and prevents any inadvertent effects that could result from them

==== Configurable ====

* The solution can be easily and safely turned on and off without inadvertent side-effects (where appropriate, not for framework solutions)
* The solution applies global configuration settings correctly and consistently
* Processing parameters, behavior and/or appearance of the solution can be adapted to requirements variations using configuration patterns separate from its core code

=== Level 4: Optimal ===

==== Efficient ====

* The solution provides acceptable performance with the minimum available hardware/infrastructure resources in the target scenario
* The solution can be applied with minimal configuration effort
* The solution can be applied, developed and maintained with minimal learning effort

==== Scalable ====

* The solution can handle/adapt to varying problem sizes (e.g. amount of data, frequency of events) without failure, inconsistent behavior or significant loss of performance
* The solution can utilize hardware/infrastructure enhancements and/or concurrency to provide better performance
* The solution can be applied in any number of concurrent instances (given the appropriate hardware and infrastructure) without failure, inconsistent behavior or significant loss of performance

==== Interoperable ====

* Different instances of the solution can, where appropriate or required, interchange data and/or process information
* The solution can, where appropriate or required, interchange data and/or process information with other relevant solutions in the target scenario
* The solution provides external APIs (application programming interfaces)

== User Experience (UX) Requirements ==

''Wikipedia: ISO 9241-210[1] defines user experience as "a person's perceptions and responses that result from the use or anticipated use of a product, system or service". According to the ISO definition, user experience includes all the users' emotions, beliefs, preferences, perceptions, physical and psychological responses, behaviors and accomplishments that occur before, during and after use.''

User experience, as a result of human-computer-interaction, involves various aspects of a software solution - both in view of its design, its functionality as well as its quality, but also personal aspects of the individual user (e.g. skills, previous experiences, cultural background), and of the situations and environments in which the software is to be used.

"Good UX" is though not a requirement in itself - but the generic name for any additional design, functional and quality requirements in view of human-computer-interaction that may be defined for a solution, and which must be met in order to achieve certain quality levels.

Even though UX as such appears to be a largely subjective matter, there are usually a number of generalizable UX requirements for any user interface.

'''Example:''' ''User interfaces which are typically used in the darkness should not blind the user, but use a reduced palette of primarily reddish colors on dark background in order to cause less or no iris contraction. If the interface is though to be used under varying lighting conditions it should be adaptable (or even auto-adapt).''

In order to be '''valid and accomplishable, UX requirements must be specific and clearly defined''' (like the above example) for the quality level for which they shall apply - even when their reasoning may be more complex sometimes.

Some general quality requirements also influence the user experience (e.g. correctness, usability, efficiency), but are not specific for the use-case and therefore usually not separately discussed as UX requirements. They are however relevant for UX evaluations and should thus be taken into account in such analyses.

== Advanced Quality Requirements ==

''Advanced'' quality criteria can be used to compare different solutions, or to define quality roadmaps for particular feature sets beyond the standard criteria.

Advanced quality criteria do not apply equally for all use-cases - in certain cases they may even constitute anti-patterns.

Advanced quality criteria do not enhance the general quality level of a solution: a level-3 solution is still of better quality than a level-2 solution - regardless how many advanced criteria the level-2 solution meets.

=== Stability ===

A solution is ''stable'' when its black-box model rarely changes, and it maintains backwards-compatibility and/or easy migration paths. Stable solutions are required for all critical dependencies, so that they can be built upon without risk for frequent regression issues or need for constant migration. Stability is especially critical in shared data models (i.e. where data are shared between different modules within the application or even across applications), and in authorization frameworks - and can thus be defined as quality requirement for a solution.

Stability is typically perceived as a sign of maturity, but can actually be taken into account already during the initial solution design. Pragmatic approaches (e.g. integrated migration, or enforced backwards-compatibility) can create stability early on without limiting or obstructing further development.

=== Generalization ===

Generalizable solutions are designed and/or implemented in a way that they can be generalized. Typically, they separate their core patterns/algorithms from the use-case specifics through parametrization and/or configuration patterns. This can be defined as an advanced quality requirement for a solution.

Generalization means to modify and/or extend the core patterns/algorithms of the solution in a way that they can be re-used in other solutions which involve the same or similar functional requirements, thereby reducing future development efforts. There is a wide range of quality attributes - "flexible", "customizable", "re-usable", "extensible", just to name a few - all of which involve different degrees of and approaches to generalization.

== Standards ==

Solutions can both define or implement standards (e.g. data standards, communication protocols, taxonomies). Standard compliance can be defined as quality requirement for a solution.

Standards can define additional requirements beyond the immediate requirements of the targeted problem, which must however be met in order to comply with the standard. Such additional standard requirements would usually be seen as quality requirements under [[#Consistent| "Consistency"]] in level 3.

Guidelines:CodingStyle

Dominic — Thu, 29 Oct 2026 12:58:43 GMT

Internationalisation

@@ Line 116: / Line 116: @@
              Card secrets will not be rendered.
      """
 </syntaxhighlight>

Main Page

Dominic — Thu, 29 Oct 2026 12:54:16 GMT

Project Conventions

← Older revision		Revision as of 12:54, 29 October 2026
Line 42:		Line 42:
	=== Project Conventions ===		=== Project Conventions ===

			* [[Guidelines:CodingStyle\|Coding Conventions]]
	* [[Guidelines:AI\|Policy for Responsible AI Contributions]]		* [[Guidelines:AI\|Policy for Responsible AI Contributions]]

Guidelines:Index

Dominic — Thu, 29 Oct 2026 12:53:37 GMT

Contributor Guidelines

← Older revision		Revision as of 12:53, 29 October 2026
Line 6:		Line 6:

	* [[Guidelines:ContributorWorkflow\|Git Workflow for Code Contributions]]		* [[Guidelines:ContributorWorkflow\|Git Workflow for Code Contributions]]
			* [[Guidelines:CodingStyle\|Coding Conventions]]
	* [[Guidelines:AI\|Guideline for Responsible AI Contributions]]		* [[Guidelines:AI\|Guideline for Responsible AI Contributions]]

Guidelines:CodingStyle

Dominic — Thu, 29 Oct 2026 12:52:16 GMT

Python

Show changes

Guidelines:CodingStyle

Dominic — Wed, 28 Oct 2026 16:17:40 GMT

Created page with "* All Guidelines == Coding Style Guide == These conventions should be followed in all code. This facilitates a team of developers working on the same code base. If each developer were to use their own style, there would be jarring changes in the code as someone read through it. This slows comprehension and can also cause spurious differences in changesets as developers alter style in frivolous ways on the code they touch. Our style guide aims to..."

New page

* [[Guidelines:Index|All Guidelines]]

== Coding Style Guide ==

These conventions should be followed in all code.

This facilitates a team of developers working on the same code base. If each developer were to use their own style, there would be jarring changes in the code as someone read through it. This slows comprehension and can also cause spurious differences in changesets as developers alter style in frivolous ways on the code they touch.

Our style guide aims to make the code base appear as if it was written by one precise punctilious programmer, rather than a a cacophony of competing coders. As with many aspects of coding and writing, there can be differences of opinion about the best style. These issues distract from the goal of writing code that works. Most project contributors have a slightly different personal coding style, but we all use the Sahana Eden style when contributing to the Sahana Eden project.

=== Quotes ===

* for string literals in '''Python''' use double-quotes <code>" "</code>, unless the string contains double-quotes
* for triple-quoted strings (such as ''Docstrings'' or ''Inline-XML'') use <code>""" """</code> with double-quotes, except:
* for ''Inline-JavaScript'' or ''JSON'' inside '''Python''' code use <code><nowiki>''' '''</nowiki></code> with single-quotes

Note though that this:

<code><nowiki>
inline_javascript = '''sometext="%s";''' % sometext
</nowiki></code>

is a '''potential bug''' - the script breaks when <code>sometext</code> contains a <code>"</code>. A safer way to do that is:

<code><nowiki>
inline_javascript = '''sometext=%s;''' % json.dumps(sometext)
</nowiki></code>

* for string literals in '''JavaScript''' use single-quotes <code>' '</code>, unless the string contains single-quotes

* for attributes in '''HTML''' (such as ''view templates'') use single-quotes <code>attr='value'</code>
* for attributes in other '''XML''' (e.g. ''XSLT'') use double-quotes <code>" "</code> (inner quotes must be escaped anyway)

=== Names ===

==== General ====

* Names should be obvious and explicit, but not overly verbose (i.e. as long as they need to be to not make people think). They shouldn't require someone to look in another file or solve a puzzle to figure out what they mean, but shouldn't take too long to write. Avoid inventing new acronyms. e.g.
bad: <code> prm_lkp</code>, <code>method_that_allows_us_to_create_a_gis_layer</code>
good: <code>personnel_search</code>, <code>create_gis_layer</code>

==== Python ====

* Class names start with an uppercase letter.
* CamelCase is for class names only.
* Constant names are all-uppercase and with underscores as word separator.
* everything else (including table names and field names) should be all-lowercase with underscores as word separator.
* Names should not be Python keywords or standard library names
* Variable names should not start with _undersore (a trailing underscore_ is acceptable in local scope, though)
* Indexes in names should be avoided (e.g. file1, file2), except where they designate new versions of classes/functions (e.g. AddPersonWidget2)

* Names for Eden-specific subclasses of web2py classes and all classes which replace existing web2py classes should have the suffix "S3" (e.g. <code>AuthS3</code>)
* Names for Eden-specific methods (not overrides) in subclasses of web2py classes should start with the prefix "s3_" (e.g. <code>s3_logged_in()</code>)
* Eden-specific classes ''can'' have an "S3" prefix to their name in order to avoid name collisions, but ideally they ''should not'' (i.e. <code>BasicCRUD</code> rather than <code>S3BasicCRUD</code>)
* Method names in Eden-specific classes do not need to (and thus should not) be prefixed
* avoid "s3" or "S3" prefixes in all other cases

* <code>DataModel</code> subclasses in <code>s3db</code> should start with the all-uppercase module prefix, e.g. <code>DVRCaseModel</code>
* <code>CRUDMethod</code> subclasses in <code>s3db</code> must start with the all-lowercase module prefix plus underscore, e.g. <code>pr_Contacts</code>

=== Docstrings ===

All classes and functions must have docstrings that explain what the class or function is intended for and how it is to be used.

Exceptions can be made where the docstring would merely repeat documentation that already exists in another place, e.g. controllers, or standard interface methods inherited from (and thus documented in) a parent class.

Acceptable style:

=== Internationalisation ===

* All user-visible strings and labels ''must'' be internationalised: <code>T("My string")</code>

=== Exceptions ===

Guidelines:Edenctl

Dominic — Mon, 26 Oct 2026 20:27:31 GMT

Switching Templates

← Older revision		Revision as of 20:27, 26 October 2026
(One intermediate revision by the same user not shown)
Line 31:		Line 31:
	\| pull \|\| Update Eden from GitHub \|\| new in Eden-6.1		\| pull \|\| Update Eden from GitHub \|\| new in Eden-6.1
	\|-		\|-
	\| template \|\| Switch to another configuration template \|\| new in Eden-6.2 ~~(not yet released)~~		\| template \|\| Switch to another configuration template \|\| new in Eden-6.2
	\|-		\|-
	\| compile \|\| (Re-)compile models, controllers and views \|\|		\| compile \|\| (Re-)compile models, controllers and views \|\|
Line 111:		Line 111:

	== Switching Templates ==		== Switching Templates ==

	* ''new in Eden-6.2 (not yet released)''

	You can switch to a different template using:		You can switch to a different template using:

Guidelines:DualHost

Dominic — Mon, 26 Oct 2026 20:25:43 GMT

Dual Host Setup

← Older revision		Revision as of 20:25, 26 October 2026
Line 2:		Line 2:

	= Dual Host Setup =		= Dual Host Setup =
	* ''new in Eden-6.2 (not yet released)''

	In certain situations, you may want to deploy Eden with the database on a separate host. Follow these steps for Debian/Linux:		In certain situations, you may want to deploy Eden with the database on a separate host. Follow these steps for Debian/Linux:

Blueprint:InlineValueSet

Dominic — Fri, 23 Oct 2026 08:59:32 GMT

Solution Ideas / Proposals

← Older revision		Revision as of 08:59, 23 October 2026
(5 intermediate revisions by the same user not shown)
Line 15:		Line 15:
	=== Problems ===		=== Problems ===

	~~Wile~~ the current <code>InlineComponent</code> concept can facilitate the inline data entry for components, it cannot be configured to use specifications from a third table to build the sub-form rows. Validation is done against the component table model alone, without taking constraints from a third table into account.		While the current <code>InlineComponent</code> concept can facilitate the inline data entry for components, it cannot be configured to use specifications from a third table to build the sub-form rows. Validation is done against the component table model alone, without taking constraints from a third table into account.

	Additionally, <code>InlineComponent</code> does not limit the sub-form to a fixed set of specifications - any number of records, including multiple of the same type, can be added.		Additionally, <code>InlineComponent</code> does not limit the sub-form to a fixed set of specifications - any number of records, including multiple of the same type, can be added. Selection of sub-form rows from a set of specifications is not supported.

	=== Analysis / Requirements ===		=== Analysis / Requirements ===
Line 23:		Line 23:
	We want a SubForm implementation that		We want a SubForm implementation that

	* generates a list of specifications (parameters) that can be selected by the user for data entry (and de-~~selected~~), permitting only one sub-record per spec		* generates a list of specifications (parameters) that can be selected by the user for data entry (and de-select, if necessary), permitting only one sub-record per spec
			* support the display of additional information about the selectable specs (parameters), such as normal ranges or instructions
	* reads these specification from a third table, including validation constraints for each individual parameter, using them to provide a suitable input field (varying SELECT or text-INPUT) and validate the input		* reads these specification from a third table, including validation constraints for each individual parameter, using them to provide a suitable input field (varying SELECT or text-INPUT) and validate the input
	* creates or updates the sub-records upon form submission, de-duplicating them by specification (parameter), so that only one record per spec can exist (or zero)		* creates or updates the sub-records upon form submission, de-duplicating them by specification (parameter), so that only one record per spec can exist (or zero)
	* supports at least one value-field, as well as additional fields for status or references (which could be boolean or choice)		* supports at least one value-field, as well as additional fields for status or references (which could be boolean or choice)
	* can be embedded and configured in <code>CustomCRUDForm</code> declarations, like <code>InlineComponent</code>		* can be embedded and configured in <code>CustomCRUDForm</code> declarations, like <code>InlineComponent</code>
			* (possibly) supports a workflow separation, where the initial planning stage allows the selection of parameters, while a later data entry stage only allows the entry of values into already selected parameters (i.e. hiding the selector); reading the current stage/mode either from the master table, or determining it from user permissions (CREATE+UPDATE vs UPDATE-only), or both

	=== Solution Ideas / Proposals ===		=== Solution Ideas / Proposals ===
			[https://github.com/sahana/eden/blob/dev/modules/core/methods/dseries.py '''DataSeriesForm'''] is a draft implementation of a widget that renders a form with selectable specifications for sub-record rows. This design has the widget control the entire form rather than only the sub-record rows, and is tailored to the ''med_analysis'' use-case rather than generic.

			The <code>DataSeriesForm</code> design could be morphed into a <code>SubForm</code> (proposed class name: ''InlineValueSet'') that can be embedded in a <code>CustomCRUDForm</code>, where it would only control the sub-record rows, analogous to <code>InlineComponent</code> or <code>InlineLink</code>. The client-side control script could use Ajax to retrieve the specifications and validate input via either an extended <code>BasicCRUD.validate</code> or a new, specific end-point. Further, it could be generalized to cover use-cases beyond ''med_analysis'', including supporting configurable secondary fields and workflow separation.

	=== Implementation ===		=== Implementation ===

	=== Feedback ===		=== Feedback ===

Blueprint:InlineValueSet

Dominic — Fri, 23 Oct 2026 08:27:02 GMT

Created page with "* All Blueprints == Inline Components with Specifications from a third Table == === Background === Certain data models define semi-abstract components, with concrete specifications and constraints for the component data determined by records in a third table (spec table). One example are medical analyses (e.g. blood tests), where the concrete analysis results that can be recorded are specified in a third table, including data types and plausible/p..."

New page

* [[Blueprint:Index|All Blueprints]]

== Inline Components with Specifications from a third Table ==

=== Background ===

Certain data models define semi-abstract components, with concrete specifications and constraints for the component data determined by records in a third table (spec table).

One example are medical analyses (e.g. blood tests), where the concrete analysis results that can be recorded are specified in a third table, including data types and plausible/permitted ranges:

* Master: <code>med_analysis</code>
* Component: <code>med_analysis_result</code>
* Specification: <code>med_parameter</code>

=== Problems ===

Wile the current <code>InlineComponent</code> concept can facilitate the inline data entry for components, it cannot be configured to use specifications from a third table to build the sub-form rows. Validation is done against the component table model alone, without taking constraints from a third table into account.

Additionally, <code>InlineComponent</code> does not limit the sub-form to a fixed set of specifications - any number of records, including multiple of the same type, can be added.

=== Analysis / Requirements ===

We want a SubForm implementation that

* generates a list of specifications (parameters) that can be selected by the user for data entry (and de-selected), permitting only one sub-record per spec
* reads these specification from a third table, including validation constraints for each individual parameter, using them to provide a suitable input field (varying SELECT or text-INPUT) and validate the input
* creates or updates the sub-records upon form submission, de-duplicating them by specification (parameter), so that only one record per spec can exist (or zero)
* supports at least one value-field, as well as additional fields for status or references (which could be boolean or choice)
* can be embedded and configured in <code>CustomCRUDForm</code> declarations, like <code>InlineComponent</code>

=== Solution Ideas / Proposals ===

=== Implementation ===

=== Feedback ===

Blueprint:Index

Dominic — Fri, 23 Oct 2026 08:02:16 GMT

← Older revision		Revision as of 08:02, 23 October 2026
Line 18:		Line 18:
	=== Feature Sets ===		=== Feature Sets ===
	* [[Blueprint:FailedLogins]] - Handling of failed logins		* [[Blueprint:FailedLogins]] - Handling of failed logins
			* [[Blueprint:InlineValueSet]] - Inline component data entry with constraints set by a third table

	== Accepted ==		== Accepted ==

← Older revision		Revision as of 13:39, 29 October 2026
Line 7:		Line 7:
	* [[Guidelines:ContributorWorkflow\|Git Workflow for Code Contributions]]		* [[Guidelines:ContributorWorkflow\|Git Workflow for Code Contributions]]
	* [[Guidelines:CodingStyle\|Coding Conventions]]		* [[Guidelines:CodingStyle\|Coding Conventions]]
			* [[Guidelines:Quality\|Solution Quality Evaluation Guideline]]
	* [[Guidelines:AI\|Guideline for Responsible AI Contributions]]		* [[Guidelines:AI\|Guideline for Responsible AI Contributions]]

← Older revision		Revision as of 12:53, 29 October 2026
Line 6:		Line 6:

	* [[Guidelines:ContributorWorkflow\|Git Workflow for Code Contributions]]		* [[Guidelines:ContributorWorkflow\|Git Workflow for Code Contributions]]
			* [[Guidelines:CodingStyle\|Coding Conventions]]
	* [[Guidelines:AI\|Guideline for Responsible AI Contributions]]		* [[Guidelines:AI\|Guideline for Responsible AI Contributions]]