Create content types for a new Getting Involved section

This looks great!

Should it also cover:
- What weekly/monthly time commitment is typically needed to fulfill the role
- How to learn the skills needed for the role
- What tasks are involved in fulfilling the role [links into the task library]
- How to step into and out of this role [some roles may have a defined period of service; others are indefinite]

Cool! Yeah, I guess each "skill" page would have more information about how to learn that skill [skill library we've been discussing on the parent issue]

Are the things under "Responsibilities" linking to the proposed "task library", or are they something different? I think they would be tasks, but not sure.

I'm also not sure what the things under "Accountable for" are.

My feeling is that Skills are another content type, rather than a Taxonomy. By convention, we normally don't want to put a lot of text/explanations on Taxonomy terms. So the skills area on the Role page would be a multi-valued content item reference to a Skill content item, rather than a multi-valued Taxonomy reference to a Skill taxonomy term. But that is a detail we can hash out in the soon-to-be-created (I hope) sister issue about creating a tool to manage a list of skills. :)

I've taken a first pass at creating some content types and fields for this on the dev site (see #9).

Some notes:

1. I created 4 content types: Contributor Role, Contributor Skill, Contributor Task, Contributor Reference
2. Looking at the mockup in #4, it seemed like the Contributor Role content type needed the following fields:
   • Body -- description text, free-form
   • Required skills (entity reference to Contributor Skill content items)
   • Skills improved/learned (entity reference to Contributor Skill content items)
   • Time commitment... This is more complicated. I think we want it to be searchable, so I divided it up by these aspects:
     - Duration: 1 hour, several hours, ..., ongoing [I made this a simple List content type but maybe should be a taxonomy?]
     - For ongoing, average time commitment per month: 1 hour, 2-4 hours, 5-10 hours [ditto]
     - A text field (not searchable) for adding more details about time commitment
   • I think Responsibilities would be an entity reference to the Contributor Task content items that you would do in fulfilling the role. Hopefully that is what is meant?
   • I did not know what to do yet for Accountable for... Not sure exactly what type of "thing" these are, or whether they really merit their own pages or should be part of the Role page instead of links? Maybe Accountable is also an entity reference to Tasks? How is that different from Responsibilites exactly? I think maybe it is just a description that is specific to the role, in which case I don't think it should be on its own page?
   • Also not sure what to do with "Opportunities for mentoring". What does this link to -- events? not sure what it is
4. Contributor Skill -- decided this needed the following fields:
   • Body -- description text, free-form
   • How to learn/improve this skill [not including Contributor Tasks/Roles that would link here -- we can make those into Views and display links automatically]
5. Contributor Task -- decided this needed the following fields, based on the template we developed here: https://www.drupal.org/node/1424502
   • Goal (free-form text)
   • Skills required [entity reference to Contributor Skills items]
   • Background and reference information [entity reference to Contributor Reference items]
   • Detailed steps (free-form text)
   • Next steps [entity reference to both tasks and roles
6. Contributor Reference -- this is for background information needed to perform tasks, such as information about the Drupal issue queue, or general Git information, etc.. The idea is that if there is information that many tasks need, instead of putting it into the Steps, it should be put into a Contributor Reference page or section. These are just free-form pages with no fields beyond Title/Body.

Anyway... that is a start. The next thing to do might be to try to enter an actual Role and its associated other pages, and see if this setup works or if the fields (undoubtedly!) need some adjustment. Also I haven't made any views yet (thought it made more sense to try creating some content first)... but my thought is if you are on a Skill page, you would see any Roles or Tasks that listed this skill. If on a Task, you would see Roles that list it. Etc.

By the way, I think we will need to think carefully when we are creating these pages. For instance, about what really constitutes a "skill". Some of the ones in the mockup may not be the right things... like "Providing documentation" is maybe not a Skill per se. The skills might be "writing in English" and ... some other things about getting processes organized? I don't know... "providing documentation" might be more of a Task?

Thoughts?

Thanks for this.

There is some overlap here with core governance, as we're also trying to present the same sort of information for core maintainer role descriptions going forward.

Hm.... There is some overlap, but I think maybe (??) the governance roles in the Drupal Core project are a separate thing? Other projects (contrib modules) do not have the same role structure, and new contributors to the Drupal project (the main audience for the Getting Involved Guide, which this is part of) would probably not be ready to step into one of the governance roles for the Drupal Core project. But maybe we can use the same area of drupal.org to house both the very specific role descriptions for the Drupal Core project and the more generic role descriptions that would encompass contrib, documentation, etc. ??

We're starting a document here now in Contribution day at DrupalCon Amsterdam attached to the child issue to list contributor roles for newcomers: https://www.drupal.org/project/drupal_org_community/issues/3091381

@mradcliff and @rachel_norfolk and I discussed this in Slack today. A few conclusions/thoughts:

Content types and fields

- See comment #10 for more questions about the content types and fields
- Roles need a one-line summary for view output [see Views below in this comment]
- The content types:
--- Role -- a "position" in the community
--- Task -- has a well-defined goal and well-defined steps that if you follow them, you will achieve the goal. Could integrate into a Role but then Role pages would get very messy (some of the tasks are quite complex). Also some (but not all) tasks could be necessary for multiple roles [such as Creating a Patch]
--- Skill -- gives you the knowledge to perform a Task or fulfill a Role. May have some suggested steps that will help you acquire the skill, but they will be more nebulous than the steps you would see for a Task, and more like suggestions than defined steps (for example, "practice xyz" or "read up on pdq").
- Roles -- we need to make sure that if someone chooses one of these roles, they would have information on how to start performing the role: who to contact (what group) and/or what to do.

Views

- Probably should make the view results more compact and not use a table.
- Maybe each Role would have a one-line summary? So we could display this and the time commitment, and people would click through for the rest.
- Skills filter should be either a select list or an autocomplete

Other

- Might be useful to have a spotlighted role block, sort of a "Here are some of the roles that people fill in the community" block -- but would not want it to be random completely -- some roles being spotlighted might scare people away

@rachel_norfolk and I (and anyone else interested) are having a meeting on Thursday at 1600 UTC to work on this. It will be in the #documentation channel in Slack. Here's a link that shows this time in other time zones:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=%23documentati...

More notes about the content types:
- anything that's an entity reference field -- we need to display it as a link (currently displayed as plain text). For example, you're on a Role page, the Skills should be links to their Skill pages
- need pathauto turned on so we have nice URLs
- need to output these new content type pages in the nice fonts/style of Documentation Guide/Page

One more thing: we may also need a content type for what is called "role groups" in the spreadsheet for #3091381: Create a list of all roles, skills, responsibilities in the drupal community -- the things like Documentation, Community, etc. -- where the role can be put into play. Relates to " we need to make sure that if someone chooses one of these roles, they would have information on how to start performing the role: who to contact (what group) and/or what to do." from column 16.

@rachel_norfolk and I got together on Zoom today and had a working session with the test site. What we did:
- Added new fields and updated the display of the Role, Skill, and Task content types
- Added some new views, so you can see related Roles on Skills pages etc.

Here are some links to pages to look at on the site (don't take the content/links too seriously -- we just put random content and cross-links in there for testing purposes):

• Find a Role page https://rnorfolk-drupal.dev.devdrupal.org/node/3089293
• Individual Role page: https://rnorfolk-drupal.dev.devdrupal.org/node/3089303
• Individual Skill page: https://rnorfolk-drupal.dev.devdrupal.org/node/3089297
• Individual Task page: https://rnorfolk-drupal.dev.devdrupal.org/node/3089291

I've updated the issue summary with a list of To Dos and questions in the Remaining Tasks section.

Overall I felt overwhelmed on this page because as a sighted user I got visually lost.

1. I think the Description = the content I'm looking at so I wasn't sure why it has a label.
2. Maybe the meta data such as Tasks, Skills required, Skills learned/improved could be moved to the right? Similar to the navigation / TOC blocks on Documentation Guide pages. That might disrupt the reader's flow though.
3. The time commitment section seems like the most important section because it's called out.
4. Getting started seems like it should be below the Description because that's probably the information I want to know to start being a Documentation editor.
5. The bottom follow-up roles seem like navigation / paging semantically. I'm not sure how best to represent that though.

I was confused about this page at first because I thought it was a task. I left the comments on the image because I think it shows my confusion. :-)

1. I initially crossed out the label here, but that's probably because I'm confused at what the main content of the page is supposed to be.
2. The first label seemed to be unnecessary because that's pretty much the main content on the page, right? Or maybe that's supposed to be links? I think that not be necessary if the resources are clearly called out in the main content of the task?
3. I also felt overwhelmed as a sighted user because of the lack of visual separation of content. But not as much. I'm guessing these Roles/Skills sections can go into a side block of some sort.

I am confused about this page without actual task content.

1. I think the goal could be displayed as a call out
2. Skills required could be visually separated from the steps and resources to complete this task.

Thanks for taking a look!

It seems like most of your comments are about formatting, and some of the formatting suggestions were already in the issue summary in the Remaining Tasks section. For instance, one of the suggestions there is

Maybe preface the title with “Contributor skill: “ automatically? Same for Task, Role pages? I think it would help clarify,

So I've taken out the word "Maybe" and replace it with "Need to".

I've also added your additional suggestions on styling to the Remaining Tasks section. I think I captured everything that wasn't already there...

Thank you for updating the issue summary. I had only a little time, and I forgot to check and compare what was there.

As an exercise, I'm trying to apply role, skill, and task break down to Core Mentoring Coordinator, Mentoring Leads, and Mentor roles from a governance perspective. I find/found it difficult to figure out wording divide between skill and task, and that probably explains a lot of my confusion above. That's a thing for a different issue though.

Here is what you'd see if you went to node/add (not sure if you are logged in to the site) -- may help clarify:

Contributor Reference Information

Background and reference information that is common to more than one Contributor Task.

Contributor Role

A contributor role that is documented as part of the Getting Involved Guide. A Role is a "position" in the community (short- or long-term).

Contributor Skill

A contributor skill that is documented as part of the Getting Involved Guide. A Skill gives you the knowledge to perform a Task or fill a Role.

Contributor Task

A contributor task that is documented as part of the Getting Involved Guide. A Task has a well-defined goal and well-defined steps.

There is additional information in the submission guidelines (which appear at the top of the node/add/[type] page in a blue box):

Task says: "A Task has a well-defined goal and well-defined steps; if you follow the steps, you will achieve the goal."

Skill says: "A Skill gives you the knowledge to perform a Task or fill a Role, whereas a Task is a set of defined steps with a defined goal. Links to tasks and roles that use or improve the skill will be shown automatically, so they do not need to be mentioned when editing/creating a Skill page."

Role says: "A Role is a "position" in the community (short- or long-term)."

Ref info says: "Use this content type to provide background and reference information that is common to more than one Contributor Task."

Hi all -

I just got off a screen share with @rachel_norfolk where we looked at the current state of stage.drupalladder.org (a version 2.0 under active development). She and I are both excited about how well the features of dl 2.0 match up with the needs of the 'contributor role' initiative. (Most folks on this thread probably remember drupalladder.org - the objective of helping people contribute to the community continues to define our priorities).

At the current rough stage of development, a visit to the staging site on your own would probably be unproductive. We are aiming to release a usable version in the coming few weeks. In the meantime, if people are available for a screen share, it would certainly be useful to the drupalladder dev team to show you what we have, get your insights and make adjustments to help ensure a good match to the needs of contributor roles.

I'll read the details of this thread for now, and look forward to connecting on how these efforts help further each other.

I had a meeting with kay_v about how to integrate Drupal Ladder with the new Getting Involved Guide structure. Some conclusions:

a) We need to make sure that our content models are compatible. Not sure they are right now. We will work on this. kay_v and team will be looking at the data model we have on the dev site and see what changes might be made to make it work better with Ladder.

b) Some confusion about Roles vs. Tasks vs. what the Ladder calls Steps and Objectives. How do we map these?

c) I think our concept of Skills is similar, but the Ladder has specific things you can do to acquire the skills, whereas our concept is a bit more nebulous.

d) Hopefully we can iterate both the Ladder and the dev site to make the content models more compatible.

e) On the new Ladder site, people will be able to propose changes to the steps as alternatives, and then vote on whether they are good or not so great changes. This may be a less daunting way to propose changes than editing a page on drupal.org permanently (with revisions). When a change is accepted as better on Ladder, we would want to get it back to the drupal.org page.

I spent some time improving this today. Focused on these To Dos (which I've removed from the issue summary):

• Remove label on Description fields
• Move the Getting Started section up on Role page
• Would be good to style like Documentation Guide/Page content types (see below, more work needed!)
• Skill page: Need to preface the title with “Contributor skill:", either automatically or as a suggestion (automatically sounds better!). Same for Task, Role pages. This would help to clarify what people are looking at, especially if someone gets to the page via a search.
• Maybe move all the meta-data (like tasks related to roles, etc.) to a sidebar block? Depends on whether we think it is part of the main content of the page, or side information. Possibly some of them could be moved?
• Remove different color background on Time Commitment on role page (makes it look more important than other information)
• Fieldset label for Time commitment on role page -- should be in bold [moved this info to sidebar and there is no fieldset]

In order to do this, I did the following:

a) Set up the 4 content types to be Panelized (hid all the fields in Admin > Structure > Content types > (type) > Manage Display, and instead used Admin > Structure > Panelizer to set them up). We'll need to export a feature eventually that exports the fields, content types, views, and panelizer settings.

b) In the drupalorg project, edited drupalorg/drupalorg.module function drupalorg_preprocess_page so that it recognizes these new types like documentation page/guide pages. See attached patch.

In the next few days, I will be working on some more styling. I kind of ran out of energy today with this much... There need to be some edits to the Bluecheese theme so that these pages look more like Documentation pages.

Here's a first go at patching the Bluecheese theme... uploading here and then will build the actual CSS and test...

Second pass.

OK! I've cleaned up the styling some:
- Made the pages formatted like Documentation pages
- Added some whitespace

Updating issue summary... and here's the Bluecheese theme patch that actually works to do this.

One of the remaining To Dos from the issue summary:

Skills filters on Role Browser page should be either a select list or an autocomplete [not sure how to achieve that???] https://rnorfolk-drupal.dev.devdrupal.org/node/3089293

@rachel_norfolk and I discussed this with @drumm on Slack today. Some notes:
- We have some other autocompletes in Views on drupal.org, but we can't turn the existing skills filters on the Role Browser page into autocompletes using the same mechanisms.
- One option would be to make Skills be a Taxonomy instead of a Content Type. They could still have fields, and since we have Panelizer, we could make it so they displayed in a similar manner as now. Autocompletes on views filters for taxonomy terms work just fine.
- Another option seems to be to make a custom autocomplete views filter in the drupalorg project.
- A third option is to not have autocomplete on the Skills filter on the Roles browser page, or to remove the Skills filters from the Role Browser. This might not be good.
- However, we could send people to a Skills browser page instead, where they could look at the list of skills, click through to one, read about it, and discover there Roles and Tasks that use or improve the skill.

I attempted to set up Contributor Skill as a Taxonomy vocabulary. Some problems:

a) Editing experience is not like editing nodes:
- the HTML editor is not showing up on the taxonomy editing pages for the rich text fields. You can set the text format but it doesn't enable the editor.
- you can't fully change the order of fields on Taxonomy edit pages (the Description field is always top, which is OK, but then there's some other stuff before the added fields -- not fully integrated really).
- when you add a taxonomy term, you end up on the add page again, not viewing the term.
- generically, I think it is kind of jarring to be creating content for Getting Involved and have Skills look like one thing and all the other content types look like another thing.

b) Permissions -- permissions for edit/create are not as fine-grained as for content types. There's just a permission for "edit all" and "delete all". Not sure what you need to add terms, probably "edit all"?

c) Output display -- I don't see a way to turn off the standard parts of a taxonomy page: the ugly list of content classified with the terms, and the RSS feed link. Could hide with CSS but that is lame.

So... I'm not sure that Taxonomy is the right solution for Skills. I've left the vocabulary on the dev site but it isn't connected with anything...

Given that, I think it may be best to set up 3 "browser" pages:

- Browse roles -- look at roles alphabetically with a keyword filter on their titles

- Browse tasks -- look at tasks alphabetically with a keyword filter on their titles

- Browse skills -- look at skills alphabetically with a keyword filter on their titles. When you get to one, you'll see a list of tasks/roles that use/improve the skill

That way we don't need an autocomplete. We just have 3 different ways to approach finding ways to get involved.

OK, I've set up some new views for browsing tasks, roles, and skills. Here's yet another Bluecheese patch.

Updating issue summary with links to role/task/skill browser pages.

Brief progress update regarding observations in #27 (thanks for having posted the notes from our conversation, @jh)

The current DL team members have looked at a few possible mods so the two data models resemble each other more closely. In the end it seems worthwhile to keep the effort a little simpler. It may make sense for the Drupal Ladder simply to extend its existing data model by adding 1:1 GIG entities, then relate them to Drupal Ladder content.

DL is close to a beta launch. We'll continue on that path and stay up on decisions about the GIG data model. We're in a good place to adjust this general integration plan as the two projects progress.

Rachel and I had a meeting today in Slack to discuss next steps. Conclusions and Plan:

1. I will create a new Vocabulary for "Contribution area", add it to Contributor Skill and Contributor Role, and to various panelizers and views. [done, needs formatting/styling]
2. Make a page describing the content types and how to contribute to the section, with links to add new task/role/skill/info
3. Make a block (?) with links/buttons to add new Task, Role, Skill, or Background Info, and display it on various pages -- or maybe just a link to the page describing the content types?
4. Rachel, I, and whoever else wants to will, in the next few days, attempt to create some real content using our content types/taxonomy. Either brand new content, or migrations of existing pages in existing Getting Involved Guide. Objective: see if the content model works well or needs adjustment. Note: When creating content, put a link at the top to where it came from.
5. If it works well, we'll consult with Engineering/Infra Team, (drumm, hestenet) to see if they have concerns.
6. Make a patch with features (plus existing patches already on the issue)

One note: I found a Skill page on the dev site called "Maintaining a Contrib Project". This should be a Role, not a Skill. I think it's going to be difficult for people to decide on the distinction between these...

I'll add this to the Issue Summary too.

I just created a page on contributing to the Getting Involved Guide -- at least a start:
https://rnorfolk-drupal.dev.devdrupal.org/node/3089309

Moved some things around on the role/task pages. Removing item from To Do list.

Thanks for taking a look at all of this!

Regarding comment #42 --

#1 -- yeah, I only added a few terms to start with. In any case, we will need to re-create all of the content (terms, pages, etc.) on the live site (there is no real way to migrate them except copy/paste), so I wouldn't put too much time into getting it perfect on the dev site. IMO what we need to do now is test the process, not worry about getting all the content right. Actually, some of the content on the dev site seems problematic. For instance:
- Maintaining a contrib project (skill) - should be a Role IMO
- Creating development environments (skill) - should probably be background information
- Teaching git (skill) -- is that really a skill? Teaching is a skill, and Using Git is a skill, but Teaching Git seems overly specific.
- Leading a meeting (task) - what are the steps? Probably is a skill.
We probably need better guidelines... or maybe those were just added quickly without really thinking it through? Unsure. Did you see the page I created about contributing to the getting involved guide?

#2 -- The theme is bluecheese on the entire site, but I agree that the specific CSS styling is not exactly the same between the new Getting Involved pages and some of the other areas of the site. There's a lot of custom code/css in the theme and the drupalorg module that determines this. I can work on that. [added to issue summary]

#3 -- We could make each Step a separate item, but I am not in favor of it actually. Sometimes I think you might have alternatives, like:

If you are on Linux:

1. step 1 L
2. step 2 L

If you are on Windows:
(other steps)

If we make Steps be individual items, I think it's too restrictive to allow something like this, which I think is pretty common. A freely-editable text block seems better to me, even though it can lead to not having steps in there. The other problem is that it would be difficult to style them as an OL list on output.

#4 -- I guess you'd have to save the item you're working on, go add the other thing, and come back (or do it in another tab). I don't think we have the ability to edit an entire task/skill as we go.

#5 -- We could make select lists for tasks/skills, but the lists could get pretty long... I am not sure how many we'll have? An alternative is to have the tasks/skills browsers open in another tab to see what's already there? As it is, keywords match anywhere in the autocomplete. Anyway, I'll add that as a maybe in the issue summary.

Regarding steps as individual items... We have a similar content structure for Task topics in the User Guide. Here's an example of a page whose steps have two sections, so it wouldn't work if we only allowed a strict list of step items:
https://www.drupal.org/docs/user_guide/en/config-uninstall.html
Just one concrete example -- several of the pages in the User Guide are like that.

One other thought: I think we should consider title guidelines, such as maybe:

Role -- Should be a noun, like "Documentation editor" or "Drupal core subsystem maintainer"
Task -- Should be a verb, like "Edit a documentation page" or "Test a patch"
Skill -- Should be a noun or -ing verb, like "PHP Programming" or "Project management" or "Public speaking"

Once we agree, we can add this to the guidelines that appear when you create a new item of these content types. I think having uniform titles for these will help people browsing lists -- it makes it cognitively easier I think. Thoughts?

This patch for the drupalorg_crosssite project should fix the styling. (thanks @drumm for the pointer!). I'll upload to the site shortly...

I'll also add those guidelines for the titles and steps. Site may be briefly broken as I patch...

OK, the site is styled better now. I've also enabled PathAuto for these new pages, and updated the guidelines.

We had a meeting today in Slack about Next Steps.

We concluded that we should probably call this new section of Drupal.org "Contribution Guide" instead of Getting Involved, to differentiate it from the old Getting Involved guide. The idea is to make the Community site/section into "where to go to find your place" (marketing, motivating, etc.), and the Contribution Guide (this section) into "find specific roles/tasks that fit your skills/interests and learn exactly how to do them" (practicalities).

Plan:

a) Rachel will make a summary of the plan, and we'll finalize/discuss at next Tuesday's regular meeting.
b) Rachel will talk to Engineering/DA about the structure/plan and see if they're on board with the content types, views, taxonomy, etc.
c) People will post here if they have feedback on the content types, views, etc.
d) Based on (b) and (c), we'll see if we need to make any adjustments to the structure/plan, and do them.
e) Make patches (existing patches plus or minus (d)), and export the Features for the views/content types/taxonomy
e) Start setting up landing pages on drupal.org for the Contribution Guide and the Contribution Area pages (Documentation, etc., corresponding to the taxonomy we are proposing -- each taxonomy term will need a landing page where you can learn more about the area)

Also realized we need a view pane/block for putting on those contribution area landing pages, which would show tasks/roles related to the taxonomy term. Adding this to issue summary in To Do section. I'll try to work on that in the next few days.

I've made some updates to the site:

a) Renamed entire the section: Contributor Guide

b) Added a new section for Contribution Areas: https://rnorfolk-drupal.dev.devdrupal.org/contributor-guide/contribution...
Discussed with @drumm -- we should probably use the generic Section and Page content types for the landing areas of the Contributor Guide

I just made two of these pages for now to illustrate how they could work, for now.

c) Made a new view pane for the Contribution Area pages, which shows the related Tasks and Roles. You can see this in action on:
https://rnorfolk-drupal.dev.devdrupal.org/contrib-guide/contribute/commu...
https://rnorfolk-drupal.dev.devdrupal.org/contributor-guide/area/documen...

d) As was suggested previously, changed the editing widget for all content cross-reference fields between Roles, Skills, and Tasks to Select lists. This should help contributors find the right references.

Issue summary is updated with links for these new things, and also took out To Dos for these things that are now done.

We had a meeting today in Slack about this project, and one action item is to create a list of the content that we will need to create on drupal.org for this project, that will orient people towards both using and contributing to this section. So, starting a list to the issue summary. Also making a note changes I made to content structure that is in an existing feature and not our new content types and views.

For the contribution areas, we'll need to have child issues where the people involved in that area can create their landing page content, as well as tasks, skills, and roles. Mentoring already has an issue, thanks to mradcliffe: #3109605: Create/migrate content for Contribution Area: Mentoring. So... I'm going to build out the list of content we need and I'll make a note of this as I do that.

Also discussed with mradcliffe today that we need to make a relationship between Skills and Contribution Areas. We came to the conclusion that the best way is to use the existing relationships between the contribution area taxonomy and the roles/tasks, along with the relationship between roles/tasks and skills. So, I'll be making another view or two (display areas on skills, and display skills on areas).

I've filled in the list of pages we need... Realized we need to create two pages of content type "Section", which I currently don't have permission to create on drupal.org. So we'll either need to ping rnorfolk to create them, or I might be able to get permission later today to get those pages started at least. I also still need to make those views noted in #53... getting on that...

OK, I've taken care of the views relating contribution areas to skills. I only used the "Skills required" taxonomy for this, not the "Skills learned" -- had to choose one and I thought that was the better one to choose. I guess we could display both but it would get a bit messy.

Also I got the two Section pages added to drupal.org so we can edit them.

Updating issue summary...

Updated w/completed tasks for created sections & areas.

Added a bunch of child Area pages and related issues. There are a few more to be done.

Updating summary with links to the child issues.

I've made a new patch for the drupalorg project, which contains the changes needed so that we can add the views to the role, skill, and task browser pages, as well as the Contribution Area pages.

Also made the first pass at exporting the feature with the new content types and views, which I've put in a separate patch so that the other patch is more understandable.

add accessibility area & issue

In general, my hope is to keep maintenance burden under control as we prepare to upgrade to Drupal 8/9 and ongoing keeping the site running. Getting the informal and formal roles in the Drupal community enumerated would indeed be a big win, but we also want to make sure what gets built isn’t more complex than it needs to be, and doesn’t lead to too many follow up issues. And getting the remaining book pages migrated, or deleted, would be a big win.

Practically, for deployment, adding and updating fields is something we have to do gently. Clearing www.drupal.org’s field cache is disruptive. Each field base, and each field instance, is a field cache clear. This will have to be deployed with a 30 minute outage / service disruption window, and/or on off-hours, like the weekend.

Permissions
Like everything else on the site, we’ll have to balance open collaboration with abuse by spammers and occasional low-quality edits. And if most users can edit something, we probably want notifications. Who will be able to edit content in these new types? Everyone in a certain role, either confirmed users, or something more restrictive? Or only maintainers of a certain section? Practically, we’ll need a list of specific permissions to add to specific roles for deployment.

Custom code
I don’t see much really custom code in the latest patches. Is there any planned?

Contributor Reference Information vs documentation/guides
Could the reference information content type be served by references to the existing documentation and guide content types? Maybe using the same “related content” fields on documentation, such as at the bottom of https://www.drupal.org/drupalorg/docs/maintenance/maintaining-packaging-...?

Similarly, it doesn’t look like the contributor skills are too deeply linked in, could those be normal documentation as well?

Panelizer
Do these pages need to be panelized? Are we planning on having any different panes configured on any of the pages? If we do get into specific panes on specific pages, that will greatly increase the complexity of future migrations. If Panelizer functionality is not needed, it would be best to stick to styling the node content, and basic blocks.

Hi @drumm, thanks for taking a look! Some responses to your review in #61:

Permissions -- we will need to discuss that.

Custom code -- all that is planned is in the patches -- a few lines here and there to make the new content types style like docs pages.

Reference information -- yes, we could use regular docs guide/pages -- probably a good idea actually. They are only referenced from Tasks pages, so yes we could probably also just use the Related content field to link them from the Task pages.

Skills -- I don't think we want to make those be a regular docs content type. They are referenced by 2 fields each on the Roles and Tasks pages: one ref for "skills you need" and one for "skills that you would improve by doing this". Also, they have a few fields to give them a bit of structure.

Panelizer -- The styling and blocks is all per-content-type, so using plain blocks would be fine. I was under the impression that Panelizer was preferred (not sure why I thought that), but if you prefer to just use the standard block placement with per content type visibility for the views that we want to display on various types of pages, we can definitely convert to doing that.

So... It looks like the To Dos for us will be:
a) Figure out permissions
b) Convert Reference Information to be a regular doc guide/page structure
c) Ditch panelizer for the content types in favor of regular blocks and node styling with per-content-type visibility

Some more thoughts on the skills content type vs using Documentation Guide/Page content types:

We need some way to identify a content item as a "Skill" per se. Why?
a) We have a "skill browser" view where people can browse for skills they want to develop or use
b) Skill pages have views blocks/panes that show the tasks/roles that will help you develop or use your skill
c) When editing tasks & roles, we have entity reference "skills needed" and "skills improved" fields. These will need to have a drop-down or auto-complete showing the available skills you can reference in that field.
d) We also have a bit of field structure on skills... could probably do away with it, but I think having fields is a good clue for people as to what they should put into the pages.

To me, these concerns say "content type" rather than "try to shoehorn this into an existing content type.

You may think you've never used Panelizer, but I know you have! You set up that page originally with the view for the roles browser. :)

Regarding Skills as a taxonomy vocabulary... I think it fits better as a content type. Why?

a) Drupal (especially 7 but to some extent, also 8/9) has very strong ideas of what should be visible on a Taxonomy page: the name of the taxonomy term, a list of all the node content that is associated, and an icon linking to a RSS feed for that list of nodes. Also, Taxonomy terms have a Description field that is built-in, and can't be removed or have the label or help text messed with, even if you wanted to -- in 7, the fields on taxonomy terms are a definite afterthought. So I think if we made Skills a taxonomy, we would end up having to override more stuff than we do if it's a content type, and definitely will be stuck using Panelizer, which we have been asked not to.

b) Semantically, we want these to be pages with content. Taxonomy is semantically a classification, not a content page. So it fits better into the content model as a node type than a taxonomy vocabulary.

c) Views of taxonomy terms are weird somehow... I think I actually tried to build this with Skills as a taxonomy and I couldn't get it to work the way it should, but maybe I'm not remembering correctly.

So... I'll make some time, probably not until Monday, to
a) Convert Reference Information to be a regular doc guide/page structure
b) Ditch panelizer for the content types in favor of regular blocks and node styling with per-content-type visibility

Meanwhile, adding Rachel's plan for permissions from #64 to the issue summary. Also adding the above To Dos and modifying the areas about the plan for content types accordingly.

And I looked through the issue summary and cleaned it up... I realized there are a couple of additional To Do items for Monday:
c) Need a block that shows the related Skills used for Contribution Area pages (via related tasks/roles) [the reverse is done for the Skills pages]
d) Breadcrumbs -- We want the Role, Task, Skills, Background info pages to appear as part of Contributor Guide
e) Update the Features patches

Spoke briefly to Rachel and we agreed Skills need 2 more fields, so moving that from a question to a To Do in the issue summary also.

Default text could be good, and I don't think we have any policies against it. (For example, if you follow certain Create Issue links, you do get some default text in the body of the issue.)

Hm... Given https://www.drupal.org/drupalorg/personas ... Maybe we just need to define what "Skilled" means for a given skill? It seems like Newcomer means "I know nothing" and Learner means "I've dabbled slightly". Skilled means that you are pretty knowledgeable. Expert seems to be more about having used the skills for some period, and Master meaning ready for leadership... So maybe for each Skill, we could just list a few specifics about what you might need to know to be considered "skilled" at the skill?

I have taken care of some of the To Dos:

a) Got rid of the background information content type, and made the reference field for that on Tasks be an alias of the standard "related content" field that already exists on d.o.

b) De-panelized the Role content type.

I'm working on de-panelizing the rest; meanwhile, here are some modified patches that I am still testing... mostly just removing some panelizing style things and removing the one content type from the patches. This is still a work in progress!

Well, that seems to have totally screwed up the styling. It seems like the Role pages, without Panelizer, don't show a right sidebar at all (even though there are blocks placed in it), and the main body of the page is not centered. I am not sure what to do because I think all of the "new style" content types (Page, Documentation Guide, etc.) are Panelized, so I am not sure how to get a new-style look without Panelizer.

@drumm if you have any suggestions for how to do this, I am listening...

I took a nap and ate some food; moving forward on this again! For the moment, styling/layout on the Skills, Tasks, and Roles pages will be screwed up.

Uploading some new untested patches (prefer to edit on my own computer and then transfer them into dev site and test, vs. editi on the site directly which is annoying since I don't like vi editor much).

OK, I was able to get Tasks and Roles pages depanelized and styled. Skills are still screwed up, but I am out of time for today. Here's a new Bluecheese patch with the style updates.

Good point. I'll take care of that. Also going to fix up Skills today, right now in fact. Thanks for reviewing!

OK, I fixed up the : stuff, and also styled the skills pages. Here's one that has a lot of content to look at:
https://rnorfolk-drupal.dev.devdrupal.org/getting-involved/skill/using-git

And this required a little more bluecheese CSS, so here's a new patch.

Still to do:
- Breadcrumbs
- Fix up the path auto and headings so it points to Contributor Guide not Getting Involved
- Block that shows the related Skills used for Contribution Area pages (via related tasks/roles)

Updated the two Contribution Area pages to show related skills (the view was already there).

I have now fixed up the path aliases (pathauto settings). Breadcrumbs... I thought this patch would work but the breadcrumbs are not showing, so I will need to get some advice from infra on how to make this happen.

Also added stub pages on drupal.org for the task/role/skill browser so am updating the summary for that. (I needed them to be present for the breadcrumb work).

Result of discussion today: we decided we needed a documentation section under the contributor guide for reference information. Created this on drupal.org:
https://www.drupal.org/community/contributor-guide/background-and-refere...
Needs updated breadcrumb.

@drumm had some suggestions in Slack (fix some nitpicks and hopefully make the breadcrumbs work)... here's a patch (untested but I need to download it on the site). I'll test and report back...

This worked almost! Slight tweak...

Aaaaand, this one actually works. We have breadcrumbs for the task, skill, and role pages, that show them as under Community > Contributor guide > Find your role (for roles; similar for skills and tasks).

I'm still not sure about the pages that we've already put on drupal.org... but this is progress.

So... @drumm (hopefully): We still have some breadcrumb issues... On drupal.org we have now created various Section and Page content items, which start here:

https://www.drupal.org/community/contributor-guide

Here is a screenshot of the header area that shows the section and breadcrumb when I'm on one of the sub-pages:

But I think what we want is it to have Community as the section, and then skip the Home > Community in the breadcrumb, which is what I did in the code for the Contributor Task pages -- breadcrumb looks like this (it's supposed to be a child of the page shown in the previous screenshot):

How can we make this happen?

The other breadcrumb problem is on this sub-page, where we are planning to put background/reference documentation:
https://www.drupal.org/community/contributor-guide/background-and-refere...
This one should show up as part of the Contributor Guide, but instead it is showing up as under Documentation:

Any ideas how we can fix these breadcrumbs?

Meanwhile, here are two new patches for Features. The drupalorg patch needed a small update for an addition to the drupalorg_drupal8_panes feature (so that the new views panes can be added to the landing pages we need). I had the update there but there was a new pane that needed to be enabled.

I spoke to @drumm today in Slack about the breadcrumbs... On drupal.org, currently the breadcrumbs for other pages in Community match what is on https://www.drupal.org/community/contributor-guide and its children now:

So, we need to:
a) Make the content type pages match this. Patch attached that should work (I'll test it as soon as I get it up here).

b) File a follow-up issue to change the community section header/breadcrumb to look more like

#3115701: Community section headers/breadcrumbs could be nicer

c) The docs page for reference information also doesn't have the right breadcrumb. @drumm pointed out that this is also true of https://www.drupal.org/drupalorg/docs so we need another issue about that.
#3115704: Documentation pages need the ability to "live" in other sections

That was almost right -- I forgot to remove a few lines for the patch that set the header to look like "Community" instead of "Drupal TM". Here's a new patch, and I'm updating the issue summary.

I think everything is pretty much ready for a review now...

We had a meeting today (transcript will be there in 24 hours; until then you can participate in the threads of the #documentation channel in Slack):
#3115708: Meeting - Getting Involved Guide - 25 February 2020

To Dos from the meeting:

1. I will add a section on Deployment to the issue summary, and make sure it contains information about the specific role/permissions we need for the new content types (the role/permissions will be created by DA during deployment).

2. After drumm/DA thinks this project is probably ready to deploy, DA will make a new clean dev site so we can test the patching/deployment steps.

3. drumm brought up several good questions in the meeting, around the ongoing use of the Contributor Guide by both its editors and the contributors who will read/use it. These questions need to be captured from the meeting thread, and discussed/answered here on the issue. I'll get the capture part done soon.

Updating issue summary with these To Do items from comment #90. So... the To do section of Remaining Tasks has grown again, and we need to resolve the answers to those questions. But they are at least listed. :) Setting issue status to needs work accordingly.

We had a quick discussion in Slack about some of the outstanding questions in the issue summary. Conclusions:

(a) We should not allow comments on Roles/Skills/Tasks (or for that matter, the Area pages). Instead, we should have a sidebar block that points people to where to create issues if there is incorrect/missing content (in the Community issue queue).

(b) For maintainers' use, we should display the created/updated dates in the view output on Roles/Tasks/Skills browsers pages, and add and option to sort the view by updated date. This would be in place of creating a separate view for maintainers.

So, adding these to the To Do list in the issue summary in place of the questions about these topics that were there already.

I took care of a few of the To Dos today:

a) Verified that all 3 of our new content types have comments set to Hidden (this was already true).

b) Created a preliminary block for the sidebar of Role, Task, and Skill pages. You can see it on:
https://rnorfolk-drupal.dev.devdrupal.org/community/contributor-guide/ta...

I'm not sure about the text... thoughts?

c) Also added this block to the Task/Role/Skill browser pages manually. This required adding it to the Allowed Content for the Page content type (so the patch to that feature, which also added the view panes for those pages to the feature, will need to be updated). [Also that will have to be done manually when we deploy, and it will need to be added to some other pages; this is already part of the Deployment steps in the issue summary.] Pages:
https://rnorfolk-drupal.dev.devdrupal.org/community/contributor-guide/fi...
https://rnorfolk-drupal.dev.devdrupal.org/community/contributor-guide/fi...
https://rnorfolk-drupal.dev.devdrupal.org/community/contributor-guide/us...

d) Updated the view output for Task/Role/Skill browser pages to show created/updated date, and allow sort by updated date (default sort is still by title).

e) Looked at permissions. It looks like we will need a role called something like Contributor Guide Editor, with the following permissions:
1. Node section -- for each content type (Contributor Role, Contributor Task, Contributor Skill): Create new content, Edit any content [do we want Delete any content too? or maybe just Delete own content?]
2. Taxonomy section -- Edit terms in Contribution area [do we want Delete too?]

f) Will need to update the patch, but waiting for the block content to be reviewed.

I just "migrated" (copy/pasted) all of what I thought was the useful content we'd created on the dev site (the text on the landing pages and task/role/skill browsers) to the corresponding pages on drupal.org. That way when the dev site goes away, we won't lose the content we already created. I'm not saying it's perfect, but I think we had some good content there, at least as a start. You can see it all on
https://www.drupal.org/community/contributor-guide
and child pages.

I didn't migrate any of the roles, tasks, or skills content (we don't have the content types on drupal.org yet, and I think a lot of the content was kind of bogus stuff for illustration, and not following our own guidelines, rather than thought out carefully anyway). I think a lot of the roles/tasks/skills content, plus the background information, will end up being migrated or adapted from the existing Getting Involved Guide anyway... it does have some good content -- it's just impossible to navigate and some of it is outdated.

By the way, we do have a library of tasks and background information already at https://www.drupal.org/contributor-tasks so that will give us a good start for Tasks at least!

I confirmed the changes in b, c, and d in #93 on the test site.

Also a couple of comments about the search. results.

1. Questions? Comments?

   I think maybe the block content could be switched around. The block title makes me think that if I have questions about this particular page, but I know that a block title is probably necessary semantically so I'm not sure what would be better. Maybe the block title "Want to Get Started Contributing?" Then the content about joining Slack. Then maybe a sub-heading about questions or comments about the guide. And then the content about submitting issues about the guide.

2. 
   1. I wanted to test myself as someone who may not know what our roles are. So I wanted to search "Writer" and expect to find "Documentation Editor" as one of the results. Maybe there's a need for a filter to search the body for a key word. Or maybe a synonym of the role title?
3. 
   1. I felt like the created/update was distracting to the title and the content. I guess that's important for maintainers, but maybe helping to make the title more visually distinct. I don't know if that will effect d.o. brand/theming?
   2. Duration values should be short enough to make it inline.

Great comments! Thanks for taking the time to review carefully and comment.

I'll work on the styling of those views output areas, and I think you're right about the search/filters, that title contains is not sufficient... I'll see what I can do.

Regarding the "Questions? Comments?" block, the intent was to provide (a) a link to create an issue if the page has problems and (b) a way to get help in fulfilling a task/role. But maybe you're right that we should also provide guidance in where to start-- and in that case, our aim would be to point people either to the Contributor Guide landing page or to the Community page, not to Slack -- I think we want this guide to be something people can navigate without assistance. ... I'll try another iteration to make this distinction clear.

Should have time to look at this later today.

I thought about the filtering by title keyword... The problem with trying to filter by a "body" keyword is that all of these content types are structured, meaning that the keyword could be in multiple fields. So, as a practical matter, I don't think we can easily use Views to filter by keyword... I think we should push people to browse by skills instead, because if they find a skill they have, such as "technical writing", it will link them to related tasks/roles. All of the tasks, skills, and roles also have the ability to filter by contribution area (such as documentation).

Regarding the block, I made some changes:
- It doesn't have a title
- I put in 3 headings. Take a look:

Regarding Views styling... I've made some changes -- take a look on the site (too many pages changed to make screenshots).

One more change: I noticed that we had Duration fields on Contributor Role, but not on Contributor Task.... seemed like an oversight! I don't think we need the things about the ongoing commitment, but I decided to just add the plain Duration field to the Task type, and display it in the views as well. And there was a small styling change needed.

How about something a bit shorter, like:

Contribute to improving this page by (link)creating an issue(endlink) describing the problem.

OK, I've updated the block. Also tightened up the wording slightly in the second section. See it on
https://rnorfolk-drupal.dev.devdrupal.org/community/contributor-guide/ro...

So, we still need to figure out permissions for editors of the Contributor Guide. Here are my thoughts:

a) For the 3 new content types (Contributor Role, Contributor Task, Contributor Skill), editors should have Create & Edit any permissions (under Node module). I am not sure if we should grant Delete any and Delete own, but I'm inclined to say no (deleting content is sometimes problematic). Editors will also need to be able to create/edit Documentation Guide and Documentation Page content in the Background Information section.

b) On rare occasions we will need to create new Contribution Area pages, which are content type "Page". I am not clear on whether we need to add permissions for that, or if we would instead add people who need to do that to the OG for the parent page? It seems like Carolyn was able to create these pages already on drupal.org... will need to consult with DA on that one.

c) "Edit terms in Contribution area" (in taxonomy module) is also needed for this part -- once a contribution area page is created, we need to create a new term in the Contribution area taxonomy, and then put in the views for related tasks. roles, and skills. (We'll need to add a writeup of how to add a contribution area page; I'll add that to the To Do list.)

d) Once someone creates a Contribution Area page, we will need to add a view pane to it in Panelizer. I am not clear on what permissions are needed to allow that, or if all editors need to be able to do that? It's a bit tricky (you have to figure out the taxonomy term ID and put it in as the view argument), so I think it's probably OK to say that a few select people would do that part. The permission for this is I think tihs one in the Panelizer section:
Node Page: Administer Panelizer content

So... My inclination is to have a role called Contribution Guide Editor that can do (a), or actually we could just give that permission to people who can currently create/edit Documentation Guide/Page pages? And then for (b) (c) and (d) we can either (1) ping someone with those permissions, or (2) create a very limited role with those permissions or (3) add those permissions to an existing administrator-level role and make sure that Rachel and I (and anyone else?) has that role.

Thoughts?

Hm.... I'm not sure if we can tie content type permissions to an Organic Group like that. Will have to ask. These content items are not actually part of the section in question.

I guess the thing to do would be to attempt to set up the permissions we need, assign them to the bacon/bacon login on the dev site, and make sure that gives that login the correct abilities. I'll try to do that either later today (unlikely to have time), or early next week (when I will have more time).

We had a discussion about this on Slack today. Conclusions:

• We can tie the create content permissions to OG. To do that, we would need to add our 3 content types as permissible content for OG additions to Section content, and then set up those permissions in the existing Editor role for Section OG (or perhaps set up a new role called something like Contributor Guide Editor)
• Although we *can* do this, it could be a barrier to contribution. So, an alternative would be to grant create/edit permissions for our 3 content types to all Confirmed users. This could lead to lower-quality docs, but our content structure should be a help.
• We need to enable the "audit trail" features that we currently have on Documentation Guide/Page content types: ability to "follow" a content item (to be notified of changes), and the feature where the revision log message generates comments (and the comment list shows a list of changes with a link to the diff).

I think we decided in Slack that we would try out (for now) giving the content item create/edit permissions to "confirmed" users. If it turns into a mess, we can revisit later. And as per #104, the permission to add new items to the Contribution Area taxonomy will remain in the purview of site admins (it should be fairly rare).

So, updating the issue summary with this plan.

Note on how to make the audit trail features work (adding to summary) from drumm on Slack.

I did some work on the dev site today:

a) Enabled "follow" flagging for the 3 new content types (Flag: project_issue_follow, which is also on the Documentation Group/Page content types).

b) Set up the follow notification settings for the 3 content types the same as it was already set up for Documentation Page.

c) Edited the content type names to not have the second word capitalized (same as the other content types on d.o).

d) Added the node changes comment field to all 3 content types, so that revisions will show up as comments.

Hm.... I ran into a problem here. We want the node changes to be available, but it seems that they are not visible unless we also have Comments enabled, and I don't think we wanted that? I'm not sure what to do... For now on new content items you add, comments are enabled, and if you revise them, you get a comment but it doesn't show the link to the diffs. This will require some work and/or thought.

So... here's the question... Should we:

a) Enable comments on all 3 content types, and have the revisions make comments (like we currently have for Documentation Guide/Page content types)? If so, we need to figure out how to display a link to the diffs in the comment stream, and how to move the comments to a separate page, because it currently looks like this page (comments at the bottom and no links to diffs):
https://rnorfolk-drupal.dev.devdrupal.org/community/contributor-guide/ro...

b) Leave comments disabled and not have the "diffs make a comment" feature.

I'm inclined towards (b), assuming that we will have a link that would show the diffs/revisions anyway... thoughts? Note that on the site right now, I have comments enabled and the revisions/comment feature set up, so there is no link to look at the revisions.

I went back to the Contributor Skill content type, and turned off the revision/comments thing for testing. So on that content type, you can instead use the regular View History link, which you can see on this content item:
https://rnorfolk-drupal.dev.devdrupal.org/community/contributor-guide/sk...

I personally think this is just fine. I don't think we need the fancy comment stuff.

So... I prefer the old-fashioned revisions view that is on the Contributor Skill, not the comments/revisions that we have on Documentation Guide content types on drupal.org (and which is currrently enabled on Contributor Role, but not quite working right because there is no link to view the changes, and the comments need to be on a separate page). Also, I don't think we need/want comments on the three new content types. So, I think we're better off sticking with the old style of revisions.

Any other opinions?

OK, it sounds like we're in agreement. I'll fix up those content types so they just use the normal revisioning system again, a bit later...

I've reset the content types so that they are using standard node revisions, not comments. Updating the issue summary. I've also made a new features patch.

I did notice something new, in creating the patch: we created a custom block for the sidebar, telling people how to report problems and get help. But there is apparently no way to get such a thing into a Feature. So I'm wondering if we should put it into code, or add it to the deploy steps? This question is now part of the To Do list in the issue summary.

I'm also not sure how to get the follow flag settings into a feature, so added that to the issue summary too.

we created a custom block for the sidebar, telling people how to report problems and get help. But there is apparently no way to get such a thing into a Feature. So I'm wondering if we should put it into code, or add it to the deploy steps?

Blocks are indeed not managed by features. Please put the creation steps and configuration in deploy steps.

I'm also not sure how to get the follow flag settings into a feature, so added that to the issue summary too.

If comments are off for the content types, there’s nothing to be notified about, so following isn’t something to be added. People will not have the ability to be notified when a page changes.

OK, sounds good! I'll add that to the issue summary.

So it looks like our only remaining task/question for this issue is to finalize the content of the help/reporting problems block... Meaning that we can probably test the deployment steps now. I'll try to do that this coming week, starting with requesting a new dev site to test it on.

Meanwhile, does anyone have any more comments on the help/reporting block, which you can see on pages such as
https://rnorfolk-drupal.dev.devdrupal.org/community/contributor-guide/ro...
(the part on the sidebar starting with "Find a problem with this page?")?

I've requested a new dev environment on #3121791: Create a drupal.org dev environment for deployment testing for Contributor Guide and will test the deployment steps once that is set up.

I tested the deployment steps today:
- Added a couple of clarifications to the steps.
- Rearranged the steps slightly
- The drupalorg patch from comment #89 failed to apply, needed a reroll in the drupalorg_drupal8_panes.strongarm.inc file. New patch attached.
- Also that patch didn't seem to update the feature that tells which items are OK to use as content in Page content, so I added a step about that to the deployment. (The feature showed up as Overridden on the Features page.)

It all went OK except for the feature override... you can see the results at https://contributorguide-drupal.dev.devdrupal.org/community/contributor-... and other pages in that section.

[Note that the only Contribution Area taxonomy/page that I updated was this one on Accessibility.]

Adding notes to the Deployment steps as to which steps Jennifer/Rachel could do (if at least temporarily given the proper permissions).

That's a great idea! We can definitely do that. We'll need to add it to the content type, then make sure it is displayed properly in Manage Display, and then redo the Features patch that has all the content types and fields in it.

I don't think we would need to redo the deployment test for that change, and since this is just one additional rich text field, we are not introducing any new complexity to the project by adding this one field (we already have a bunch of similar fields in this patch).

Um... I am not impressed by how that link talks about the impact of a role in the Drupal project. It seems to be talking about belief in purpose... I don't see how exactly that will help people write a good statement about the impact of the Role page they are creating on drupal.org?

Definitely better!

I don't think we should include this link, but I liked some of the ideas in: https://www.efars.cals.vt.edu/eFARS/documents/WritingImpactStatements.html
It's about writing impact statements for research grants, which is not exactly what we're after here... but it made me think... It says that an impact statement answers the questions "So what?" and "Who cares?" and "What's the payoff?". It also says that an impact statement (in this context anyway) starts by stating the problem, and also tells how the work solves the problem and who benefits from it being solved.

From the link in #123, I got the idea that we should be talking about how this role contributes to the overall goal (which for the Drupal project I guess is to have great software, documentation, and community? or something like that). After all, this is the Contributor Guide.

And this made me think about something I heard years back: that to have a sustainable open-source project, we need to focus first on building a strong community, and we would get great software as the result (rather than making the software the first goal).

So... How about if our field description is something like this:

Describe how fulfilling this role contributes to the overall goal of the Drupal project: building an inclusive, sustainable community that builds great software and documentation. See https://www.tanveernaseer.com/encouraging-your-employees-to-reach-for-th... for inspiration.

???

Is there something we can link to that talks about the overall goal of the Drupal project, in terms of creating community, software, and docs?

The issue summary says:

We do not, however, have a canonical place where somebody new to the community and looking to increase their involvement can browse the possible roles and understand

Well, we have:

• https://www.drupal.org/drupalorg/docs/user-accounts/user-roles-and-permi...
• https://www.drupal.org/drupalorg/advanced-user-roles

I find this particular feature request rather orthogonal to the already existing user roles and permissions. At least it need to be stated up front whether this is intended to replace the existing roles and permissions, or to be something existing in parallel or as an addendum.

I don't doubt that this is well-intended. But as the proposal stands, the logistics of creating and managing the deliverables assumed delivered the ordinary users of this framework seems overwhelming. I would be willing to put up something like this to receive a considerable sum of money by means of a project grant, but not for doing something like helping out in the webmasters issue queue with no other reward than being "credited" for fixing stuff.

However, all the stuff listed on my homepage that you quote from are rooted in in existing roles and permissions.

All those things (i.e. "Drupal Licensing Working Group", "Drupal GDPR Compliance Team", "packaging whitelist", "webmasters", "Project ownership") are community projects. They are exactly the same as module projects. They just don't use the parts of module projects that manages a repo that contains code and releases.

And in order to have the roles I list, I am simply a "maintainer" of those projects.

So if you think of this as "examples of the roles we are looking to build a consistent model around", you seem to ignore the fact that there is already an data model that are used to manage the roles and permissions of these projects, and it is one that is a lot simpler and more adaptable (IMHO) than what is proposed here.

So you have to make a decision about whether what you are building is going to replace this existing data model that has served us rather well for some time, or whether you want a build a data model to "capture" roles that are orthogonal to the existing framework. I can't think of many such, but "mentor" is probably one of them.

But if you can state up front that you're not planning to replace the existing rather simple, but workable, framework of roles and permissions, I shall quietly slip out the back and not disturb again. And you can go ahead and create new content types and taxonomies and when you're done, hope that someone will be willing to use it and volunteer the time that will be needed to create and maintain all the data that such a framework is going to need to be of any use.

We are not looking to change any role or permissions, other than maybe to the new content types we are making.

Fine! It was your comment #129 that got me worried.

Back to comment #126, I think there still could be some question about the last proposed wording for the Impact field on the Role contact type... So I'd like to suggest this instead:

Describe the impact of fulfilling this role on the Drupal project and community. See https://www.drupal.org/about/values-and-principles for inspiration.

That page on drupal.org talks specifically about impact and how it relates to the Drupal project, so even though the moon project link is interesting, this one may be more relevant. I also like this wording of the first sentence better than "Describe how fulfilling this role contributes to the overall goal of the Drupal project.". Thoughts?

We discussed this on Slack today and everyone agreed #134 is a good field description. So, I'll implement that and get it into the patch, and then I think we are ready to go!

One other outstanding item: the content of the "get help and report issues" sidebar block. I discussed this with Carolyn and Rachel today in Slack. Carolyn had two outstanding suggestions:

1) Shorten the first part to say

Help improve this page: create an issue describing the problem.
(with "create an issue" as the issue link)

2) In the second part, she also suggested:
"Drupal community's many aspects" to just "Drupal community"

Rachel and I agree. So I'll make those changes, and the new field, and make a new patch, and I think we'll be ready to go.

OK, I've made the changes: updated the block text and added the field. Updating issue summary to reflect this, and here's a new patch.

This issue really needs a new title. Also now #1414988: [Meta/Plan] Create a new Getting Involved Guide section is really a duplicate of this issue.

Thankyou so much for working on this.

In the following pieces of code, there is an extra space between "they" and "demonstrate" that should be removed.
And "behaviours" should be "behaviors".

'description' => 'The Demonstrated by field should enable a person to make an objective decision whether they demonstrate this skill. Consider adding examples of behaviours that demonstrate this skill at different competency levels, such as those that are "learning", "skilled", "expert" or "master" as defined in the <a href="https://www.drupal.org/drupalorg/personas">Drupal.org personas</a>.',

t('The Demonstrated by field should enable a person to make an objective decision whether they demonstrate this skill. Consider adding examples of behaviours that demonstrate this skill at different competency levels, such as those that are "learning", "skilled", "expert" or "master" as defined in the <a href="https://www.drupal.org/drupalorg/personas">Drupal.org personas</a>.');

Thanks very much for taking a look!

Here's a new patch, which I made by carefully editing those two lines in the earlier patch (it appears twice in the Features patch: once when the field is defined, and the other time when it defines the translation strings).

Thanks for the interdiff...always helpful with these massive patches.

The spaces have been removed from those two pieces of code and the word "behavior" now conforms to Drupal coding standards/style guide.
https://www.drupal.org/drupalorg/style-guide/content

Thanks, marking RTBC.

Here's an updated patch for the drupalorg module, based on the assumption that #3115701: Community section headers/breadcrumbs could be nicer will happen, and also a reroll.

I'm setting this back to Needs Work, because (based on DA feedback from drumm in our latest Slack meeting) we need to put some attention to the styling of the pages. I'm working on it... will report back (with new patches) when that is done.

Rachel and I spent some time on Hangouts earlier today discussing fixes to the styling and header text. I then spent some time updating the Bluecheese theming and the main View (various displays).

So, here's a new patch for Features, and one for Bluecheese. Note that for Bluecheese, the header styling that was in a previous patch has been removed -- that is handled on #3115701: Community section headers/breadcrumbs could be nicer.

Some links to look at to review these changes:

• Role browser: https://rnorfolk-drupal.dev.devdrupal.org/community/contributor-guide/fi...
• A role: https://rnorfolk-drupal.dev.devdrupal.org/community/contributor-guide/ro...
• Task browser: https://rnorfolk-drupal.dev.devdrupal.org/community/contributor-guide/fi...
• A task: https://rnorfolk-drupal.dev.devdrupal.org/community/contributor-guide/ta...
• Skill browser: https://rnorfolk-drupal.dev.devdrupal.org/community/contributor-guide/us...
• Two skills: https://rnorfolk-drupal.dev.devdrupal.org/community/contributor-guide/sk... and https://rnorfolk-drupal.dev.devdrupal.org/community/contributor-guide/sk...
• Area page: https://rnorfolk-drupal.dev.devdrupal.org/contrib-guide/contribute/commu...

Let me know what you think... hopefully it's a bit cleaner and nicer! Not so many lines and more consistent spacing at least...

Taking information about Contributor Area content and moving it to new related issue #3137918: [Meta] Create content for Contributor Area sections.

Taking out the part about creating content for the landing pages, and putting it on a child issue. There are now also related issues for creating role, task, and skill content, and migrating the existing content from the old Getting Involved Guide.
#3138011: Finalize landing page content for Contributor Guide
#3138007: Create content for the identified roles, skills, and tasks
#3137918: [Meta] Create content for Contributor Area sections
#3138004: Migrate content from Getting Involved to new Contributor Guide
(These all have this marked as parent issue or related issue already.)

- For the new taxonomy vocabulary (Contribution Areas), permission to edit its terms should be added to all elevated content editor or administrator roles (Not sure which roles they would be?), so that several people could be pinged to add terms (this should be fairly rare to need new terms added).

This sounds somewhat like issue tags, which can be edited and deleted by

• administrator
• content administrator
• content moderator
• webmaster

that is about 50 people.

That sounds good. I don't know if I have any of those roles now, but that is probably OK, maybe Rachel does?

Updating issue summary:

• I deployed the drupalorg_crosssite change, https://git.drupalcode.org/project/drupalorg_crosssite/commit/c8ed5a9 that code got a minor refactor upstream, still it is only adding 3 content types to an array.
• Both drupalorg & bluecheese have 3089403-contributor-content branches. Changes so far:
  • Replaced a hard-coded color with the variable.
  • The panelizer-related exports confused me, since I thought I mentioned not Panelizing these in Slack. That switch to blocks did happen, which is great. Those vestigial exports are now gone.

Updating the issue summary with drush commands to grant permissions, which is what I’ll do on staging as part of the deployment process.

That sounds good. I don't know if I have any of those roles now, but that is probably OK, maybe Rachel does?

You both have more than one of those roles.

RE panelizer, those lines showed up in Features exports and I did not edit them out. Glad they are gone now. I was wondering about them. Anyway we are not using Panelizer on the new content types.

Depending on the timing of this getting on drupal.org -- if it happens this week, I would be happy to help with any of the deploy steps that I can help with. Probably that would be these steps [details in issue summary]:
- Add views and blocks to the Roles, Skills, and Task browser pages
- Fix up the contribution area pages.

There's no reason for you to have to do those steps. THANKS for working on this!

This looks good to deploy in the next few minutes. (Sorry for the short notice, it happens to be around the low-point for site traffic today.) I can handle everything except the panelizer arranging, steps 11 & 12.

I made a few last changes to the theme additions. Hopefully none are regressions, we can always handle those in followups. The changes were close enough together so that separate commits would have been a hassle.

+.node-type-contributor-role, .node-type-contributor-task, .node-type-contributor-skill {
+  .region-sidebar-second, #aside {
+    .block-views {
+      h2 {
+        font-size: 1.2em;
+        color: $body-text;
+        font-weight: bold;
…
+.node-type-contributor-role,
+.node-type-contributor-skill,
+.node-type-contributor-task {
+  #aside {
+    .block-views {
+      h2 {
+        font-size: 1.5em;
+        font-weight: normal;

These looked like redundant styles to me, and they did not fully override .new-style. My updates could have taken these styles out of the community/contributor-guide page.

+.view-display-id-block_role_fields {
+  .views-field-field-commitment-description {
+    p {
+      margin-bottom: 0;
+    }
+  }
+}
…
+  .field-name-field-how-to-get-started {
+    .field-item {
+      p {
+        margin-bottom: 0;
+      }
+    }
+  }

I collapsed these into one set of styles, with more-simple selectors. And I added a smaller margin between paragraphs, except the last paragraph.

I also adjusted the padding a bit in the .view-getting-involved-reference-blocks within the View blocks.

Wooooooot! Thanks! I will take care of those content-related steps in the deploy.

The deployment plan up though step 10 is now done. 🎉

With some help from drumm and hestenet to sort out permissions, I was able to do steps 11 and 12 of the deployment.

Also realized I forgot one part of step 10, which was to also make the Contributor Guide Help block available for Section content at admin/structure/panelizer/node/section/allowed -- so amending the issue summary for posterity.

One note: I do not apparently have permission to add terms to the Contribution Areas taxonomy, although I can edit terms. hestenet added the needed terms for now, but it would be helpful to fix that eventually.

I am also not sure what drumm and hestenet did to modify the pages so I could add block content to them. I am concerned that going forward, we may have that problem again as we add new Contribution Areas pages. But have not tested this.

I think we can mark this as Fixed! I verified that the views seem to be working, and can add new content of the 3 types. Now comes the actual content phase... see
#3144893: [Meta] Content for the new Contributor Guide

One note: I do not apparently have permission to add terms to the Contribution Areas taxonomy, although I can edit terms. hestenet added the needed terms for now, but it would be helpful to fix that eventually.

Looks like the permissions taxonomy gives us are “Edit terms in Contribution area” & “Delete terms from Contribution area”, both of which look like they are properly granted. I’m sure there’s a core issue somewhere to improve the permission options, or hopefully it is already improved in Drupal 9.

I am also not sure what drumm and hestenet did to modify the pages so I could add block content to them.

Any node that’s Panelized might be at the node type default, or customized for that node. It seems like your account wasn’t allowed to do the initial save as custom.

That permissions question is weird. I mean, we can all add issue tags dynamically on drupal.org, right? But I guess it's the page-level permission in taxonomy_menu() in D7 that is the problem -- indeed the add form requires admin taxonomy permission. ?!?

In D8/9 the permissions are on the entity level, not at the page/form level, and there are separate permissions for create/delete/edit on a per-vocabulary basis (plus administer taxonomy).

So I guess for now when we want to create a new Contribution Area, we'll need to ask someone to create the terms who has Administer Taxonomy permission.

[edit, added] And get someone who has full Panelizer permissions to change the page to Customized so the views/blocks can be added.