devel-announce July 2024

devel-announce@lists.fedoraproject.org

5 participants
34 discussions

F41 Change Proposal: Retire Python 2.7 (system-wide)
by Aoife Moloney 01 Jul '24

01 Jul '24

Wiki - https://fedoraproject.org/wiki/Changes/RetirePython2.7 Discussion thread - https://discussion.fedoraproject.org/t/f41-change-proposal-retire-python-2-… This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == The {{package|python2.7}} package will be retired without replacement from [[Releases/41|Fedora Linux 41]]. There will be no Python 2 in Fedora 41+ other than PyPy. Packages requiring {{package|python2.7}} on runtime or buildtime will have to deal with the retirement or be retired as well. == Owner == * Name: [[User:Churchyard|Miro Hrončok]] * Email: mhroncok(a)redhat.com == Detailed Description == The {{package|python2.7}} package with the Python interpreter in version 2.7 was kept in Fedora after upstream EOL ([https://devguide.python.org/versions/#versions 2020-01-01]) only to make it possible for Fedora users to test their software against the Python version shipped in RHEL 7, CentOS 7 and RHEL 8 and to support remaining packages that could not be ported. * Fedora 41 is to be released in October 2024, nearly 5 years after the upstream EOL of Python 2. * RHEL 7 will reach the end of its maintenance support 2 phase on [https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux/rhe… 2024-06-30]. * CentOS Linux 7 will reach end of life (EOL) on [https://www.redhat.com/en/topics/linux/centos-linux-eol 2024-06-30]. * RHEL 8 Python 2.7 application stream retirement date is [https://access.redhat.com/support/policy/updates/rhel-app-streams-life-cycle June 2024]. === Dependent packages === Based on `repoquery --repo=rawhide{,-source} --whatrequires python2.7`, the following packages still depend on {{package|python2.7}}: * {{package|email2trac}} runtime and buidltime. [https://bugzilla.redhat.com/1738907 rhbz#1738907] -- no response from package maintainers since 2019. This package will be retired if not fixed. * {{package|flatpak-builder}} runtime only (shebang) in the tests subpackage. [https://bugzilla.redhat.com/2249819 rhbz#2249819] -- no response from package maintainers since late 2023, but we belive this is a buggy dependency. * {{package|flowcanvas}} buidltime only. [https://bugzilla.redhat.com/1805233 rhbz#1805233] -- no response from package maintainers since 2021. This package will fail to build and will be eventually retired when Fedora 41 goes EOL if not fixed. * {{package|kdissert}} buidltime only. [https://bugzilla.redhat.com/1807513 rhbz#1807513] -- no response from package maintainers since 2020. This package will fail to build and will be eventually retired when Fedora 41 goes EOL if not fixed. * {{package|qt5-qtwebengine}} buidltime only. No bugzilla. Package bundles Python 2 for build in EPEL 9 and can probably do the same on Fedora. Alternativelly, can use PyPy (untested assumption). This package will fail to build and will be eventually retired when Fedora 41 goes EOL if not fixed. * {{package|qtwebkit}} buidltime only. [https://bugzilla.redhat.com/1807543 rhbz#1807543] -- no response from package maintainers since 2021. The latest meaningful response: "The plan is still to try to sunset Qt4WebKit entirely". This package will fail to build and will be eventually retired when Fedora 41 goes EOL if not fixed. ==== GIMP ==== The rest of the dependents exist merely for GIMP. * {{package|gimp}} * {{package|gimp-layer-via-copy-cut}} * {{package|gimp-resynthesizer}} * {{package|pygobject2}} * {{package|pygtk2}} * {{package|python2-cairo}} [[Changes/Gimp_3|GIMP will be updated to GIMP 3 with Python 3 support]]. Python 2 dependencies of GIMP will be retired. If by the time of the Fedora 41 Beta Freeze (2024-08-20) no Release Candidate of GIMP 3 has come around, we will postpone the retirement of Python 2 to Fedora 42. == Feedback == See the [https://discussion.fedoraproject.org/t/f41-change-proposal-gimp-version-3-s… GIMP 3 discussion] for feedback from the GIMP maintainer. == Benefit to Fedora == The Python maintainers will no longer regularly backport security fixes to Python 2.7 in RHEL, due to the the end of maintenance of RHEL 7 and the retirement of the Python 2.7 application stream in RHEL 8. We provided this obsolete package for 5 years beyond its retirement date and will continue to provide it until Fedora 40 goes end of life. Enough has been enough. We do not wish to simply orphan the package, as we are afraid it would not receive proper care if taken by somebody else. If there are potential maintainers interested in maintaining Python 2 in Fedora beyond Fedora 41, they can talk to us and demonstrate their ability and will to take care of Python 2 by joining the maintenance early. Users who need to run their application in Python 2 should do so on a platform that offers support for it. Running applications on unsupported Python is dangerous. Developers who still need to test their software on Python 2 can use containers with older Fedora releases or unsupported CentOS/RHEL versions. == Scope == * Proposal owners: ** Coordinate closely with the GIMP maintainers. ** `fedpkg retire python2.7` before the beta freeze if GIMP is ready. ** Remove `Recommends: python2.7` from {{package|asv}} and {{package|tox}}. * Other developers: ** Retire or fix the remaining dependent packages. * Release engineering: [https://pagure.io/releng/issue/12175 #12175] * Policies and guidelines: Using Python 2 is already forbidden for Fedora packages. * Trademark approval: not needed for this Change * Alignment with the Fedora Strategy: n/a == Upgrade/compatibility impact == Unless Python 2 stops being installable, we do not plan to Obsolete it. Users who upgrade to Fedora Linux 41+ from earlier releases with Python 2 installed, will likely still get it, but they will receive no support. == Early Testing (Optional) == Do you require 'QA Blueprint' support? N == How To Test == Try installing {{package|python2.7}} on Fedora Linux 41+. It should fail. == User Experience == Some users might be unhappy about this, but we decided to do it anyway. We cannot keep legacy software forever, Fedora Linux is not that kind of Linux. == Dependencies == * [[Changes/Gimp_3]] == Contingency Plan == * Contingency mechanism: postpone to Fedora 42 * Contingency deadline: A week after Beta Freeze * Blocks release? No == Documentation == There is no more Python 2 in Fedora Linux 41+. == Release Notes == There is no more Python 2 in Fedora Linux 41+. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 0

F41 Change Proposal: IPU6 camera support (self-contained)
by Aoife Moloney 01 Jul '24

01 Jul '24

Wiki - https://fedoraproject.org/wiki/Changes/IPU6_Camera_support Discussion thread - https://discussion.fedoraproject.org/t/f41-change-proposal-ipu6-camera-supp… This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Integrate support into Fedora for Intel IPU6 attached MIPI cameras using the IPU6 CSI-receiver (isys) driver which has landed in kernel 6.10 together with libcamwera's 0.3 software ISP support and Firefox' recent support for using cameras through pipewire. == Owner == * Name: [[User:jwrdegoede| Hans de Goede]] * Email: hdegoede(a)redhat.com == Detailed Description == Many new laptops models have a camera-sensor which is directly attached to the laptops CPU/SoC over a MIPI CSI2 databus instead of using a USB webcam module talking the standard USB UVC protocol. These cameras require a lot of work on the software side to go from the raw Bayer data received over the CSI2 bus to an usable image. This includes both controlling things like exposure and gain settings on the sensor as well as a lot of processing of the raw data, such as debayering and whitebalancing. Adding support for these complex cameras is tricky because: * Applications can no longer directly use /dev/video now * Supporting ISPs (if supported in the kernel) requires ISP model specific knowledge in userspace * Vendor's 3A algorithms for auto-exposure/gain, auto-whitebalance and auto-focus are secret and need to have open-source counterparts written and tuned * Instead of having a single UVC driver this requires CSI-receiver + ISP + sensor drivers in the kernel * Different IPU6 laptop models use different sensors, hw-enablement needs to be done on a laptop by laptop basis * Good image quality requires per sensor/laptop model tuning Parts of these challenges are solved by libcamera. For now the aim is a simple stack with good enough image quality for video-conferencing. The plan is to have a stack consisting of: # Mainline kernel sensor driver (currently supported: ov2740, ov01a10, hi556) # Mainline kernel IPU6 CSI receiver driver # libcamera simplepipeline-handler using software ISP for debayering + 3A # pipewire with pipewire libcamera plugin # pipewire support in Firefox (see [https://jgrulich.cz/tag/pipewire/ Jan Grulich's blog]) == Feedback == No feedback yet. == Benefit to Fedora == Currently IPU6 cameras do not work OOTB in Fedora, with the new libcamera software ISP stack these should work OOTB on laptops with supported camera sensors. == Scope == * Proposal owners: ** The IPU6 CSI receiver has landed in 6.10 and some bugfixes coming to 6.11 have been added as downstream patches ** libcamera needs a couple of small downstream-patches to enable the simple pipeline for the IPU6 ** pipewire libcamera plugin needs to be made part of the default Workstation patch-set * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (not a System Wide Change) * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: Yes (better hw-support should help getting more users) == Upgrade/compatibility impact == The pipewire-plugin-libcamera needs to be automatically added on Fedora workstation updates to ensure things work. Otherwise there is no upgrade impact. == How To Test == Test plan will be filled in as soon as all necessary bits have landed in rawhide. == User Experience == IPU6 cameras on laptops with supported camera sensors should work OOTB after this change, with the caveat that the image quality may be less then ideal. The hope is that image quality will improve over time as the software ISP and its 3A algorithms get improved. With that said it is unrealistic to expect the image quality to become as good as the proprietary stack which has extensive image quality tuning done on a per laptop basis. == Dependencies == IPU6 support not only depends on kernel and libcamera support taken care of by the proposal owner, but also on pipewire camera support and on Firefox pipewire camera support. == Contingency Plan == ATM IPU6 cameras do not work at all. So unless the new kernel driver actually causes regressions outside of the camera functionality no contingency plan is necessary. == Documentation == N/A (not a System Wide Change) == Release Notes == Fedora 41 has added support for IPU6 cameras on laptops using ov2740, ov01a10 and hi556 sensors. This support requires using applications which support accessing cameras through pipewire such as Firefox. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 0

F42 Change Proposal: Opt-In Metrics for Fedora Workstation (system-wide)
by Aoife Moloney 01 Jul '24

01 Jul '24

Wiki - https://fedoraproject.org/wiki/Changes/Metrics Discussion thread - https://discussion.fedoraproject.org/t/f42-change-proposal-opt-in-metrics-f… == Summary == The goal of this change proposal is to provide the Fedora community with accurate, representative data about the real world use of Fedora Workstation. By doing this, we believe that we can accelerate the development of Fedora Workstation, and ensure that it improves in line with our users’ needs and requirements. '''Protecting user privacy is of utmost importance for this initiative.''' To this end, the service will only collect generic, standardized data, and will never collect anything that is personally identifying. It will also, of course, be fully open source. On the server side, the data will be stored in a way that prevents user identification. '''Another important aspect of the initiative is that it will be run in a transparent manner, and will be governed as part of the Fedora project.''' A new SIG will be responsible for the service, and will be open to community participation. It will publish analyses of the data which has been collected, provide documentation about how the service operates, will share samples of the database data, and will respond to requests from the community. '''Finally, we intend to ensure that metrics reporting is fully under the control of end users.''' Metrics collection will default to off, and will only be enabled through a clear on/off prompt in initial setup. Users will be able to view the data that has been collected locally, and will be able to remove the client software from their systems, should they choose to do so. To address concerns that the community might have, the change owners have created a [https://pagure.io/fedora-workstation/blob/master/f/notes/metrics-privacy-tr… privacy and transparency checklist], which will be updated as the initiative progresses. == Owners == * Name: [[User:aday|Allan Day]] * Name: [[User:catanzaro|Michael Catanzaro]] * Name: [https://docs.fedoraproject.org/en-US/workstation-working-group/ Fedora Workstation Working Group] == Current status == The proposal is to deploy a pre-existing data collection system - called Azafea - for Fedora Workstation. Azafea has both client and server components. Significant work is required to make a wide scale deployment of Azafea possible (see scope section below). This updated proposal obsoletes [[Changes/Telemetry | the original proposal]]. * Targeted release: [[Releases/42 | Fedora Linux 42]] == Detailed Description == This section includes a detailed description of each aspect of the metrics proposal. === Data that will be collected === All collected data will be anonymous: * We will not collect identifying information, such as email addresses, online account details, and IP addresses. * We will only collect generic, standardized information. For example, we want to collect data on which apps are used, but we will never collect data on which websites are viewed or which files are opened. * Server side, each metric will be stored separately and will not be linked to other metrics from the same system. This will prevent user fingerprinting through the cross-referencing of anonymous information. All of the code in the data collection system will be open source and available for public inspection. The data we plan on collecting will fall into the following categories: {| class="wikitable" style="margin:auto" |- ! Category !! Examples |- | Hardware details || CPU, graphics, cameras, which peripherals are present. |- | System settings || The display language, which input methods are used, which accessibility features are enabled. |- | Desktop usage patterns || Which apps are used, how many open workspaces there are, how often each system settings panel is opened. |- | Performance reports || Disk and memory usage. |- | Evidence of problems || Counts of system crashes, OOM events, app crashes. |} For more detailed information, see the [https://pagure.io/fedora-workstation/blob/master/f/notes/metrics-to-collect… preliminary list of metrics that we want to collect]. This list indicates the purpose of each metric that we hope to collect. === Steps to ensure anonymity === The [https://pagure.io/fedora-workstation/blob/master/f/notes/metrics-to-collect… metrics that we hope to collect] are all generic in nature, and do not contain personal or identifying information. To prevent accidental collection of identifying information, the data we collect will be filtered on the client side, so that only known, standardized variables are included. For example, when recording which apps are used, we will only record known package names, in order to prevent custom apps with identifying metadata from being recorded. Wherever possible, the system will aggregate data locally prior to upload. For example, it can report the number of times that a feature was used in a week, instead of the exact time whenever it is used. This method further increases anonymity by reducing the precision of the data that is reported. We will only deploy the service once it has undergone a thorough period of testing, during which we will verify that the database is only being populated with anonymous data. (Data from the testing phase of the system will be permanently deleted.) === How metrics data will be used === We anticipate that the data we collect will drive myriad improvements within Fedora as well as the wider ecosystem. These improvements include: '''Resource prioritization''' - knowing which hardware, features and apps are used most will allow developers and partners to focus their efforts where they will have the most impact. '''Software improvements''' - data about usage and performance patterns can drive optimisations in existing software, in terms of both technical and UX design. '''Configuration enhancements''' - decisions about default settings and the default composition of Fedora Workstation can be based on observed usage patterns. '''Better development practices''' - we aim to promote and encourage user and data driven development practices through this work. To achieve these impacts, analysis of the collected data will be published and circulated to the relevant developers and projects. === Who will have access to metrics data === In the interests of transparency, we will put the following mechanisms in place for viewing the data that is collected: # Raw data from the database will be published during the testing phase, prior to wide scale deployment # Members of the community will be able to join the metrics SIG, in order to get full ongoing access to the data # After deployment, a randomly selected sample of the database will be published (once it has been manually checked) # Members of the community will be able to request the SIG for copies of the database, which will be shared privately This proposal is an attempt to balance the need to protect privacy with the need to provide transparency. We have a high degree of confidence that the database will only contain anonymous data (see “how will we ensure that the system only collects anonymous, generic data?”). However, there is always some risk that something could go wrong with data collection. Out of an abundance of caution, we therefore only want to share data once it has been manually checked. === Approval for changes to the metrics system === Any changes to the metrics system and its governance arrangements will require approval by FESCo. This will include any changes to the: * metrics data that is collected * the metrics SIG (its rules, role, composition, membership terms) * the technology used * changes to the UI for user opt in/opt out * hosting of the infrastructure or involvement of 3rd parties === User control === The proposed system aims to ensure that users are always in control of metrics collection on their systems. This will be achieved through the following: * The setting for metrics collection will enabled/disable both local metrics collection and data upload * Metrics collection will be off by default * Metrics collection will only be enabled through an explicit opt in from the user, which will be presented as part of initial setup * It will always be possible for users to disable metrics collection from the system settings * It will be possible for users to view the metrics that have been collected locally on their systems * It will be possible for users to remove the metrics collection components from their systems, using dnf === Metrics system components === The metrics system would be composed of server and client Azafea components. An Azafea server deployment consists of five components: 1. an nginx proxy server, 2. azafea-metrics-proxy, 3. redis, 4. azafea itself, 5. a Postgres database nginx proxies HTTP requests to azafea-metrics-proxy, which is itself a simple HTTP server that adds batches of metrics into the redis database, where they will be fetched by Azafea and stored into Postgres. The client side consists of the following components: * eos-metrics - a D-Bus interface that applications and services may use to record events, plus a GObject library that provides a simple API around the D-Bus interface * eos-event-recorder-daemon - the service that actually implements the D-Bus interface: it collects metrics recorded via D-Bus, batches them together, and sends them to the metrics server at predefined intervals * eos-metrics-instrumentation - the component that calls D-Bus methods on eos-event-recorder == Feedback == The [[Changes/Telemetry|initial version of this proposal]] generated a huge amount of feedback and debate. We have put a lot of time and effort into engaging with this feedback, and the proposal has been substantially changed in response to it. We are grateful to the Fedora community for enabling us to improve the proposal in this way. We know that there were issues with the original proposal, and that these led to serious concerns amongst the community. We hope that the updated proposal addresses these concerns, and look forward to receiving further feedback. The following is a summary of the key points from the discussion so far, along with details of the steps that have been taken in response to them. Additional information is also included in the [https://pagure.io/fedora-workstation/blob/master/f/notes/metrics-faq.md FAQ] If we have missed something from that discussion, please let us know. === Opt in or opt out? === The original proposal specified that metrics upload would be disabled by default, and that the UI setup would include an on by default switch to allow users to opt out. This aspect of the proposal attracted by far the most negative feedback. As a result of this feedback, we have changed the proposal: we now propose that initial setup will show an explicit yes/no prompt which has no default value. We recognise that feedback about the opt-out UI reflected wider concerns about the privacy and transparency of the metrics system, which we have addressed through other changes. === Proposal omissions === We received feedback that the original proposal omitted key details from the proposal, including: * The benefit to Fedora * Which metrics will be collected * That each metric will be stored separately and will not be correlated * How members of the community will be able to access the database * Whether users will be able to view the local data that has been collected on their systems * That the metrics packages can be removed using DNF * The policy through which the collection of specific metrics will be approved This information has now been added to the proposal. === Ability to view the entire data set === This was a frequent request in the feedback we received. We understand the motivation to have transparency and to verify what data is being collected. “Who will have access to the data?” contains an updated proposal which we hope will satisfy this desire while also preventing potential privacy issues. === Risks to anonymity if the metrics server is hacked === This was another major subject of discussion, with various concerns being raised. We are confident that it will not be possible for the administrators of the metrics system to identify or fingerprint users under normal operation of the metrics server. We also want to emphasize the generic nature of the metrics we want to collect. We have also committed to: * Take steps to minimize risks, such as having short retention of server logs * Manage the server through the metrics SIG, so that members of the community can contribute their expertise * Document the infrastructure setup for the metrics server once it has been setup, in order to solicit further feedback These points have been added to our [https://pagure.io/fedora-workstation/blob/master/f/notes/metrics-privacy-tr… privacy and transparency checklist]. The metrics server will not store IP addresses or entire batches of metrics data. However, we acknowledge that, if Fedora infrastructure is compromised, an attacker could begin recording this information. We acknowledge this as a risk of the system. === Local data collection === The original proposal specified that local data collection would default to on, while upload of that data would default to off. Some pointed out that this would be a privacy risk. In the new version of the proposal, local data collection will only be enabled after the user has consented to metrics collection. === Other suggestions=== We received various other suggestions during the debate about the original change proposal. These included: ==== Provide fine-grained user control over which data is uploaded ==== This would add complexity to the system and to data analysis. We are also unsure how much these fine-grained controls would be used in practice. This is not something that we are rejecting outright, but it is unlikely something that we ourselves would be able to add to the initial version of the system. ==== Only collect some metrics for a fixed time period ==== We agree that this makes sense for some metrics and we have added this to our [https://pagure.io/fedora-workstation/blob/master/f/notes/metrics-privacy-tr… privacy and transparency checklist], as a future work item. ==== Restrict metrics collection to a small sample of users ==== The main issues with this approach would be ensuring that the sample is representative, and our ability to detect issues experienced by subsets of the user base. ==== Collaborate with a trusted third party ==== The idea behind this suggestion was for us to get additional oversight and input from an organization that has expertise in data privacy issues. We’d be very happy to do this, but are unsure who that third party would be. We are open to suggestions! ==== Adopt differential privacy techniques ==== [https://desfontain.es/blog/friendly-intro-to-differential-privacy.html Differential privacy] would potentially allow Fedora systems to submit inaccurate data to the metrics server, while ensuring the overall data set is still representative and useful. We would welcome collaboration from Fedora community members interested in improving the metrics collection system to adopt such techniques. == Benefit to Fedora == See “What will the data be used for?” == Scope == * Proposal owners: this change requires substantial technical and nontechnical work from the change owners. This will include: ** Properly packaging eos-metrics, eos-event-recorder-daemon, and eos-metrics-instrumentation for Fedora ** Modifying eos-metrics-instrumentation so that it does not send events that are not approved for use in Fedora ** Creation of the metrics SIG and its various policies and procedures ** Documentation for end users and members of the community * Other developers: Community Platform Engineering (CPE) will need to host the metrics server infrastructure. * Release engineering: [https://pagure.io/releng/issues/11514 #11514] * Policies and guidelines: see "How will data collection be approved?" * Trademark approval: N/A (not needed for this change) * Alignment with objectives: there are currently no [https://docs.fedoraproject.org/en-US/project/initiatives/ Fedora Initiatives]. However, the generated data will be broadly applicable to Fedora community activities. == Upgrade/Compatibility Impact == There are no special technical challenges in this regard. Metrics collection will only be enabled in response to an explicit opt-in by the user, through a UI in either gnome-initial-setup or gnome-control-center. gnome-initial-setup is only shown for new installs, meaning that the only way to enable metrics on an upgraded system would be through gnome-control-center. == How to Test == Testing is not currently possible. Instructions will be provided when this changes. == User Experience== The user experience for the system will consist of: # In initial setup, a UI to choose between metrics collection being on or off. There will be no default in the UI and users will have to explicitly choose one of the two options. # In the privacy Settings, a switch to turn metrics collection on or off # User documentation about the service # A method to view locally collected metrics data == Dependencies == Packages wanting to collect metrics data will need to depend on eos-metrics. For example, to collect statistics about Settings usage, the gnome-control-center package would need to depend on eos-metrics in order to send a metric to eos-event-recorder-daemon. == Contingency Plan == * Contingency mechanism: remove the eos-metrics, eos-event-recorder-daemon, and eos-metrics-instrumentation packages from the workstation-product comps group, and rebuild any packages that gained a dependency on eos-metrics. * Contingency deadline: beta freeze * Blocks release? If the change is incomplete, it will need to be reverted before release. == Documentation == This feature depends on several different upstream projects, each of which have their own documentation. Client side components: * eos-metrics has online docs at [https://github.com/endlessm/eos-metrics/blob/master/data/com.endlessm.Metri… D-Bus interface XML]. API documentation is also built and installed in a docs subpackage. * eos-event-recorder-daemon and eos-metrics-instrumentation components do not have online documentation at this time. Server-side documentation: * [https://github.com/endlessm/azafea-metrics-proxy/tree/master/docs/source Azafea-metrics-proxy] * [https://github.com/endlessm/azafea/tree/master/docs/source Azafea] * [https://azafea.readthedocs.io/en/latest/events.html Events recognized by the server] (this documentation is currently focused on use by Endless OS rather than by Fedora, and includes documentation of many events that are no longer sent by Endless OS) == Release Notes == These will be provided if the proposal is approved and successfully implemented. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 0

Fedora & AI Survey Now Live Until July 16th
by Aoife Moloney 01 Jul '24

01 Jul '24

Hi folks, Thank you for contributing to our discussion on what kinds of questions are useful for us to ask our community on the subject of AI in the Fedora ecosystem [1]. We've created a short survey [2] based on the questions that were proposed that we feel are general enough for everyone to feel comfortable answering, and from the answer we receive, the council and other governing bodies of the project can start formalising some AI-related focus areas and develop solid guidelines for the use of AI in the project ecosystem. The deadline is July 16th, it shouldn't take more than a few minutes of your time to complete, and I will be sending some reminders between now and the closing date too. A quick reminder that this is not our annual contributors survey, and that survey will be launching soon with a section around AI too. I want to offer an advance apologies for any survey-related fatigue, but when it comes to creating AI guidelines for the project and understanding how our community is doing and feels about the project, this AI survey and the contributor survey is truly the best way to get that feedback and create actionable stuff 'n' things from your direct responses. Kindest regards, Aoife [1] https://discussion.fedoraproject.org/t/ai-survey-questions-what-should-we-b… [2] https://fedoraproject.limequery.com/142117?lang=en -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce July 2024