From Fedora Project Wiki

(Clean up)
(Redirect Package Maintainer wiki links to docs.fp.o)
 
(10 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{draft}}
== What you need to know ==
== What you need to know ==


* We do not do any work on the production server that has not been ''tested'' and ''documented''.
* We do not do any work on the staging or production servers that has not been ''tested'' and ''documented''.
* We do not alter code directly on our test server, or the production server. You can use a [Inlocal sandbox to do experiments.
* We do not alter code directly on our staging server, or the production server. You can use a [[How to install Drupal|local sandbox]] to do experiments.  Public tests are done on the development server.
* Our goal is to write as little custom code as possible for Insight. Wherever possible, we prefer to use community provided modules that are well tested and actively maintained.
* Our goal is to write as little custom code as possible for Insight. Wherever possible, we prefer to use community provided modules that are well tested and actively maintained.
* All code must be [[Package Review Process|packaged]] before it goes on the test or production server.
* All modules must be [https://docs.fedoraproject.org/en-US/package-maintainers/Package_Review_Process/ packaged] before they goes on the development, staging, or production servers.
** Packaging ensures the site structure can be recreated in the event of a catastrophic failure.
** Packaging ensures the site structure can be recreated in the event of a catastrophic failure.
** Packaging ensures other community members can benefit from our work.
** Packaging ensures other community members can benefit from our work.
* To the maximum possible extent, our customizations need to be deployed as [http://drupal.org/project/features Features] so they we can recreate them easily as well.
* If you are helping develop the Insight platform, it is your responsibility to keep other team members updated on your work. You can do this through the mailing list and through tickets assigned to you.
* If you are helping develop the Insight platform, it is your responsibility to keep other team members updated on your work. You can do this through the mailing list and through tickets assigned to you.


== How to make a change ==
== How to make a change ==


Unfortunately, we don't have the ability to simply capture changes in a source code management system like git. So we must have some process to provide change in an orderly fashion.  It's not orderly for everyone to simply make whatever changes they want without attention to our goals.  At the same time, the process needs to be easy to follow and conducive to change.
Here is our change process:
 
* Make sure a ticket is filed in the [https://fedorahosted.org/fedora-infrastructure/newticket?component=FedoraInsight&version=Test&cc=logistics@lists.fedoraproject.org fedora-infrastructure Trac] to record the issue you're fixing or the desired enhancement. Whether you file the ticket, or take up an existing ticket, make sure you have assigned the ticket to yourself, and accepted it using the Trac interface.
'''Proposed process:'''
* Make sure a ticket is [https://fedorahosted.org/fedora-infrastructure/newtplticket?component=FedoraInsight&version=Test&cc=logistics@lists.fedoraproject.org filed in the fedora-infrastructure Trac] to record the issue you're fixing or the desired enhancement. Whether you file the ticket, or take up an existing ticket, make sure you have assigned the ticket to yourself, and accepted it using the Trac interface.
* Test your proposed fix [[How to install Drupal | on your own sandbox]], to make sure you know what you're changing, and that it works. The team can provide a copy of the production data if needed. ''(NOTE: This depends on the backup_migrate module, currently in package review.)''
* Write down the steps needed for the change as a comment in the ticket you filed, so the team mailing list receives a notice.
* Try the steps in the test server, being careful to ''exactly'' follow the steps you wrote. If you find a discrepancy, ''update the ticket'' so it is accurate. No one will mind if you need to alter your steps! But it's important that we be able to track the correct series of changes you made.
* Add the keyword ''insight'' in the Trac ticket's ''Keywords'' field, so the change will be discussed at the next meeting.
* Add the keyword ''insight'' in the Trac ticket's ''Keywords'' field, so the change will be discussed at the next meeting.
* Once the team approves the change, it will be made on the production server.
* Use the process outlined on our page for [[Insight development using Features module]] to develop your feature. Make sure to test your proposed fix [[How to install Drupal | on your own sandbox]], to make sure you know what you're changing, and that it works. The team can provide a copy of the production data if needed.
* Write your progress in the ticket you filed, so an update comes to the team's mailing list automatically.  Communicating your work is important!
* Once the team approves the change, it will be made on the staging and then production servers.


In this way, as a team we can look over and approve each other's changes to ensure we're constantly improving our service.
In this way, as a team we can look over and approve each other's changes to ensure we're constantly improving our service.
=== Updating the Fedora Insight theme ===
There's a separate page to show you [[how to update the Fedora Insight theme]].
[[Category:Fedora Insight]]

Latest revision as of 11:21, 9 October 2021

What you need to know

  • We do not do any work on the staging or production servers that has not been tested and documented.
  • We do not alter code directly on our staging server, or the production server. You can use a local sandbox to do experiments. Public tests are done on the development server.
  • Our goal is to write as little custom code as possible for Insight. Wherever possible, we prefer to use community provided modules that are well tested and actively maintained.
  • All modules must be packaged before they goes on the development, staging, or production servers.
    • Packaging ensures the site structure can be recreated in the event of a catastrophic failure.
    • Packaging ensures other community members can benefit from our work.
  • To the maximum possible extent, our customizations need to be deployed as Features so they we can recreate them easily as well.
  • If you are helping develop the Insight platform, it is your responsibility to keep other team members updated on your work. You can do this through the mailing list and through tickets assigned to you.

How to make a change

Here is our change process:

  • Make sure a ticket is filed in the fedora-infrastructure Trac to record the issue you're fixing or the desired enhancement. Whether you file the ticket, or take up an existing ticket, make sure you have assigned the ticket to yourself, and accepted it using the Trac interface.
  • Add the keyword insight in the Trac ticket's Keywords field, so the change will be discussed at the next meeting.
  • Use the process outlined on our page for Insight development using Features module to develop your feature. Make sure to test your proposed fix on your own sandbox, to make sure you know what you're changing, and that it works. The team can provide a copy of the production data if needed.
  • Write your progress in the ticket you filed, so an update comes to the team's mailing list automatically. Communicating your work is important!
  • Once the team approves the change, it will be made on the staging and then production servers.

In this way, as a team we can look over and approve each other's changes to ensure we're constantly improving our service.

Updating the Fedora Insight theme

There's a separate page to show you how to update the Fedora Insight theme.