[FOLIO-1930] Reconcile "FOLIO Development Team Home" on wiki and dev.folio.org Created: 01/Apr/19  Updated: 04/Nov/22  Resolved: 04/Nov/22

Status: Closed
Project: FOLIO
Components: Documentation
Affects versions: None
Fix versions: None

Type: Task Priority: P3
Reporter: Peter Murray Assignee: David Crossley
Resolution: Done Votes: 0
Labels: devdoc
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to FOLIO-1673 Update team definitions on dev website Closed
Sprint: DevOps Sprint 151
Development Team: FOLIO DevOps

 Description   

There is a divergence of developer documentation between the FOLIO Wiki and dev.folio.org.



 Comments   
Comment by Peter Murray [ 01/Apr/19 ]

Starting conversation with Cate Boerema, Jakub Skoczen and David Crossley. A few people have pointed out that the "FOLIO Teams" table on https://folio-org.atlassian.net/wiki/display/FOLIJET/ is considerably more useful than the Developers directory and Product Owners directory wiki pages, and I agree. As I went looking at the content in that space I found that this table is only the tip of the iceberg. There is:

  1. The table of teams including product owners, lead PO, development team leads and scrum master. (The columns for EBSCO stakeholders and EPAM management can presumably be left on this page.)
  2. The "Meet the Teams" list, under which some teams have team-specific documentation
  3. The "Engineering Process" and "Testing" and "How-to articles" page hierarchies (some of which overlaps with content on dev.folio.org)
  4. Other content listed in the space sidebar (some of which overlaps with content on dev.folio.org)
  5. EPAM team calendar

I think #1 can clearly be moved out of the EPAM space and into someplace like https://folio-org.atlassian.net/wiki/display/COMMUNITY/ (or maybe create a https://wiki.folio.org/display/DEVELOPERS/ ...see below).

The content in #2 leads me to wonder if each development team needs their own wiki space (as we have set up for each of the EPAM teams) where they can keep their team-specific documentation.

The content in #3 and #4 makes me wonder why this content wasn't added to 'dev.folio.org' to start with. Does the wiki's reduced friction over making pull requests to https://github.com/folio-org/folio-org.github.io/ mean we should move developer documentation to the wiki? Should we create a https://wiki.folio.org/display/DEVELOPERS/ space where documentation has a more "provisional" status before moving to 'dev.folio.org'?

The calendar (#5) seem specific to the EPAM teams, so it should stay where it is. (On quick glance I didn't see anything that went beyond the EPAM teams.)

Thoughts?

Comment by Cate Boerema (Inactive) [ 02/Apr/19 ]

I'm fine with all your suggestions. The only thing I might disagree with is that the the "FOLIO Teams" table on https://folio-org.atlassian.net/wiki/display/FOLIJET/ is more useful than the Product Owners directory. The FOLIO teams table lists the POs by team, while the PO directory lists them by area of focus. Both seem valuable

Comment by Peter Murray [ 04/Apr/19 ]

Good point about the content of the Product Owners directory being valuable on its own. I'll take that into account.

Jakub Skoczen and David Crossley ... thoughts?

Comment by Zak Burke [ 04/Jun/21 ]

I stumbled on https://dev.folio.org/community/ today. The “Subproject core teams” section looks to be either out of date and no longer relevant, maybe replaceable by the Wiki’s “Team vs. module responsibility matrix” (https://folio-org.atlassian.net/wiki/display/REL/Team+vs+module+responsibility+matrix). Likewise, I have never heard of the “Engineering core team” but maybe it’s been supplanted by the Tech council?

If we don't have time for the full reconciliation task, I think it would at least be valuable to remove content that is out of date and no longer accurate since it's so easily accessible (linked from the top-level navigation of dev.folio.org).

CC: David Crossley

Comment by David Crossley [ 04/Nov/22 ]

Done via pull/1203

Generated at Thu Feb 08 23:16:56 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.