Implement Drupal.org changes tool

Here's a blow-by-blow of my testing today... I marked things that I think are blockers to wide-spread use of the tool as "major." These are just my opinions though; it's more important what works for the people actually working on Drupal.org.

General, "getting to this page":

- Major I had no idea how to get to this page. I see now that it's up at the top in the dark blue navigation that's so small and out of the way that I never, ever look there. Recommend moving it to the sidebar instead, or even making it the home page of infrastructure.drupal.org, since the text that's there could just as easily be "header text" for the view, and then there's a reason to visit this site repeatedly.

Change request add form: https://infrastructure.drupal.org/node/add/change-request

- The phrase "Change request" implies that "someone else" is going to do this and you are making a "request" to them to complete it. Not sure that's how we want things set up given the DA staff of 1 developer who has not yet figured out how to either clone himself or bend space and time to create more hours in a week. ;) I would call it "Proposed change" or something more like that.
- Major: "Assigned" field only shows me options of "- Restricted access -" over and over. Should probably remove the field then from people without proper access. (Maybe Conditional Fields can do this?)
- I'm able to move my change request directly to any stage in the drop-down. Maybe this is fine (especially since many of these things *are* "under development" atm rather than in ideation phase), but I wonder if we need some docs that the field description links to to explain what each of these phases mean and how an issue moves from one to another.
- "Primary initiator" is a weird phrase. :) Maybe "Request coming from" or something? And it seems like we could do with some help text that explains what people are supposed to select here when and why/how this information is used.
- "Dev Tools: Project" seems like a pretty big bucket; I would probably have split out at least issue queue + project. I guess though the thinking here is that's where we have a tech lead, so that's where it goes.
- Major: I think we're missing a "Drupal.org issue #" (or actually probably #s) as a required field. Would like to keep the conversation on these nodes to purely "meta" stuff about moving the node from one workflow state to the next: patches, architectural discussion, code reviews, etc. should take place in the issue queue IMO, because that's how the community works.
- "[#xxx]" doesn't work for easy cross-linking. :( Don't think this can be helped, since this tool is on a different subdomain. But double the reason to have the field above IMO.
- Major-ish: When I selected "Under development," the "Demo url" field popped up *above* where I was looking. I wouldn't have caught it except I went back to scan through the fields before submitting my comment here. We should weight that field properly so it shows up under the "Stage" selector.
- The "Deployment" tab on this form lacks content of any kind when the "Stage" is set to "Idea" or "Planning," which looks like a bug. Some empty text to the effect of "Deployment instructions are only applicable once a change is under development" would be nice.
- I like the "Test plan" fieldset here. Very nice.
- "Summary" and "Implementation plan" duplicate information in the Drupal.org issue summary. However, this is probably fine since it's easier to find this way and more explicit.
- Major It occurs to me that we probably need an "Architecture review" here as well, that indicates the tech lead has signed off on the approach. This doesn't mean that it's necessarily secure or performant; that comes later, once the code is complete.

Change request node: https://infrastructure.drupal.org/node/83

- Minor, but annoying The bullets of the list items for the tabs are poking out.
- Major I'm very confused by why "Stage" is sitting there on view as a field for me to change. Why not also any of the other fields? Oh. I see. That's a filter for a view that's totally empty. :( That's super unclear. Can we hide that unless there are comments of any kind, perhaps? In fact, do we need this at all, given that the comment clearly indicates what stage it was against?
- Talking to myself, I think the reason this was done was to separate out Melissa's concern about ideation-stage comments cluttering up the comment stream during the "ok, this might actually happen" phases. Given that though, I wonder if a better approach is to turn comments off on these nodes when they're in the ideation phase, and instead make a required field that's "Idea discussion URL" for people to enter their discussion. This would either be a g.d.o/drupalorg post or an issue in the D.o issue queue (we should figure out which).
- Minor, but annoying I'd like to be able to edit my comments like I can on Drupal.org.
- It's kind of annoying I can't both change properties like "Stage" and leave a comment at the same time. I had hoped filling in the revision log would do that like it does on Drupal.org but that was sadly not the case.
- Major The bad thing about the above, is that unlike Melissa's original mock, I can't see when other metadata properties such as "Stage" or "Deployment instructions" or "Passed security review" updated, so we have to trust that people are going to manually add a comment that this happened. However, they're probably not going to do that, since the issue queue takes care of that notification for them, so that's what they'll expect here as well. Can we not use node changes module here as well?

Oh, also really, especially, crucially important:

We need a search box on this view to prevent duplicate posting

:)

Oh, and "Component" should likely be multi-select. Features (such as semver) can span multiple areas.

Aaaand feels like we could use a "Critical" or so on the impact scale, for things like https://infrastructure.drupal.org/node/88 or things that e.g. leave the site completely unusable.

If the goal of this tool is still to make it exceedingly clear what changes are actually intended for deployment on Drupal.org and where those changes are at in the process, then I don't think this is ready yet.

High level feedback

Limit the tool to Drupal.org changes, like its name
It's already a challenge to provide clarity for Drupal.org alone. Putting infrastructure.drupal.org on the component list (or making it a *.drupal.org tool) really interferes.

I would also expect the landing page to be aimed at an audience looking to know what changes are coming up rather than a view showing every issue.

Create separate landing pages for Ideation and "Accepted" changes
I've been skeptical about wrapping the ideation and deployment processes together because ideation is super-noisy and detracts from the clarity of what work is actually being done. With the two processes technically united, which is fine, I still expect to see them separated, with separate landing pages.

Document how to use this tool
Before it leaves the committee, it seems really important to explain who is intended to do what with this. Who can enter a change request? Who will look at that request? How long is it expected until you receive a response?

I understand that Leadership committees and DSWG will at some point indicate that a change is desirable and that when it is implemented, it will actually be deployed (if it passes the necessary gates), but I can't see where or how that happens.

Detailed feedback
I'll get to more of this later today, I hope.

One minor thing: The components seem like they're supposed to match the Leadership tech lead areas. Git should be Version control as there's a lot more than Git involved in that areas.

Edit:
I'm going to more or less ignore the "Idea" stage. I think it may be more nuanced than what is present, but since I don't know much about how that process will work, there's not too much to say. Just to give an example of the nuance that may be needed, ideas move from a request for general feedback to discussion to a more detailed proposal and it can help people to be more productive when they know which of those phases it's in.

I marked things that I think are blockers to wide-spread use of the tool as "major." These are just my opinions though; it's more important what works for the people actually working on Drupal.org.

When I suggested the tool, it wasn't primarily for people actually working on Drupal.org. Rather, just the opposite.

The goal of the tool was so that DA executive director, the Board, and the community could see at an easy-to-digest-glance where Drupal.org work is at. I completely agree with you that it absolutely *must* be usable by the people doing the work - staff, contractors, and volunteers.

But it also must be quickly grok-able by exceptionally busy people, especially ones who contribute to priority and funding decisions for the site and those who are pouring their life-energy into it.

Like I said in IRC, if the purpose has shifted, then most of my feedback is off-target. If not, then we have a great foundation that needs more attention to presentation and detail.

Maybe the Dev Tools Leadership team could be the first feedback group - have them answer questions like: What's the highest priority? What's blocked? etc. and see how long it takes to determine that. After that reading, then look into how they'll use it. It'll be important to let docs speak for themselves and NOT to provide verbal explanations about what things are for. That's what should give some stability in the face of turnover, vacations, new people, etc.

Those are all fair points. I guess I meant that more on the "create" side of change request nodes, which will disproportionately be done by people who work on Drupal.org vs. observers. But I think you've pointed out some good things to fix on the "view" side for the broader audience.

So I am considering to step back and split out ideation related stages into a separate 'idea' content type, with most fields matching those of 'change request'. This will also make it easier to introduce features like voting on ideas without further complicating the 'change request' content type. The main drawback is more manual work for people, since when the idea is 'accepted' someone will need to go and create 'change request' for this idea. Additionally people who work on D.o will have to watch 2 places instead of one - ideas and change requests. Thoughts?

Big +1 to that. I really don't think that level of manual work is overly onerous, and the benefit we gain from separating "we are discussing the concept itself and seeing if it makes sense" vs. "Ok, we need Foo module and Baz update function and etc." is significant. Realistically, the vast majority of ideas will never make it to implementation, let alone deployment. And the discussion involved in refining a vague idea (which almost all of these start as, since no one wants to do an ass-load of work on something that might not happen) to something actionable enough to implement could be 50s or 100s of comments long in and of itself (and is useful to refer back to, to see if the points brought up still make sense N months/years later). One other thing that the board has been vocal on in relation to this tool is that they don't want us having to spend a huge budget to maintain/bug fix/upgrade it to D8/etc., preferring instead to spend that money on infrastructure/features that help benefit the wider pool of contributors, so the closer we can stick to stock "core" (and "core-like contrib"), the better, IMO.

One thing I would like to discuss though (and I can't remember if it was in #5 or not) is where discussion actually happens during implementation. My strong feeling has been that these deployment nodes should be around the "meta" discussion related to changing the workflow of the change itself, but that all implementation details/architecture discussion/patches, etc. should happen on D.o in regular ol' issues because that's how every other project on the face of Drupal.org works.

---

So in other words, my ideal flow would be:

a) Someone gets an idea. They post an "Idea" node to the "Ideas board" part of infrastructure.drupal.org (whatever it's called; doesn't matter). The idea is filed against a particular area of the site that overlaps with the D.o teams we've appointed. Then one of the things the teams should do whenever they meet is go through new/"hot" ideas posted in their sections and discuss them.
--- Note that the vast majority of the community won't be looking here, at least not at first (or possibly ever, since it's off-site). We should figure out some kind of communication strategy here; maybe an ongoing section of the "Drupal.org Team Notes" posts on the DA site to "feature" a few new/hot/etc. ideas? Not sure.
--- Also, I'd highly recommend these to be "wikis" so that over time as things get sorted out, the main post can be updated with whatever the latest consensus is, and save people from reading 200+ comments to figure it out.

b) Discussion happens in the comments of the "Idea" node, most of which has to do with whether or not this is actually a good idea, what benefits we get, if there are alternatives we could do instead, though knowing our community it'll probably dip into implementation too, like possible modules that could be used, blah blah. That's fine.

c) At some point, the D.o team for that section will either decide "this isn't happening," "this is a good idea," or "this idea is so amazing and would benefit so many people that we should expedite it." (And should be able to set a public workflow setting on the idea node to reflect this. See http://drupal-association.ideascale.com/ which allows you to mark ideas as "in review," "in progress," or "complete.")

d) Assuming it's not the first, the Drupal.org tools team would create two things:

1) An issue in the appropriate queue for the implementation itself, where patches are posted and reviewed, detailed architecture discussions happen, etc. (Again, mirroring every other project on Drupal.org, for ease of entry/to benefit from "follow" functionality, easily spin-off and show related issues, etc.)
2) A "Drupal.org change" node (or whatever) for infrastructure.drupal.org that tracks the workflow of the change itself (architecture, dev, staging, deployed, etc.). This would have required fields both for the originating idea as well as the implementation issue.

e) The section owner for that part of the site then participates in the d.o issue and updates the d.o change record as major things happen (workflow changes, etc). Comments on the change node would be of the form of "so-and-so reviewed this at [link to the d.o issue comment] and it looks good from a security POV." and then checking that box off. (To prevent "forking" discussions from the issue queue, maybe we want to limit comment access on change nodes to d.o team members?)
---

If you're counting, that actually would make three places for discussion on a given topic:

1) The idea itself (basically most "feature request" issues on the d.o issue queues would move to this instead.)
2) The implementation issue(s). These would happen in whatever is the most appropriate queue, to pull in maintainers, etc. from that project who don't have a general need/desire to follow the d.o changes tool.
3) The "change tracker" node on infra.d.o for visibility to the "outside" world on what's happening on d.o at any given time, since they absolutely cannot be expected to follow 35+ issue queues to figure this out.

So while that's more complex, each of these communication mechanisms has a very distinct "use case," so I would think/hope it'll actually help focus discussion during each "phase." I know when I was implementing the issue UX changes it was *really* nice to be able to tell people trying to side-rail the implementation to bikeshed the design, for example, "Nope, sorry, we're implementing the spec. If you want to change the spec, go discuss it over here instead."

I think we're pretty aligned. Change record taking place of "meta" issue is mostly what I meant.

So then things from https://drupal.org/node/2159409 that would be on the change record node would be:

- Current status of where it's at, e.g. https://drupal.org/comment/8445685#comment-8445685
- Instructions for volunteers on how to help implement this change (was in the issue summary before Neil blew it away)
- Talking about what's in scope/out of scope of the feature, e.g. https://drupal.org/comment/8294289#comment-8294289
- Talking about who's taking what part, e.g. https://drupal.org/comment/8290071#comment-8290071

...correct?

The one part I'm less sure of is "How are we gonna actually implement this thing"-type coments, ala:

https://drupal.org/comment/8304435#comment-8304435

While that discussion is "meta," and so could qualify as belonging on the change record, it often more naturally sits alongside the patches once you see them in action and what they do. See https://drupal.org/comment/8294265#comment-8294265 and https://drupal.org/comment/8297651#comment-8297651. I would hate for that type of discussion to be "forked" into two places... some of it on the change record when whoever (most generally, the appropriate section owner) first sat down to scope things out and make a recommendation, and then more of it on the implementation issue(s) as people actually start following the plan and hit issues and need to work around them. And then you need to read both full discussions to understand what the real current status of things is. :\

And while it's easy to say "Ok, just have it all on the change record then," and while that might even seem to make logical sense, it's an "unnatural" fit for the way we generally work in Drupal. We generally use the implementation issue for the single point of reference for all implementation-related discussion, so you can see the various twists and turns it went through and why, years after when you hit some kind of a problem with it ("git blame" ftw).

So what I would hope we do is something like making the change record the definitive "implementation spec" that gets updated by the section owner/main implementor as situations change "on the ground," but that the actual discussions about how and when to make those types of implementation changes happen in the issue queue where the full community can participate the way they do everywhere else.

I think we might get a little very high-level 'how to implement' type stuff on the 'change request' node. E.g. at the very beginning section owner would say - implementation issue should be opened in the /drupalorg queue and custom hook_something implemented against that module. Or they could say - just use available module X, open an issue in the infra queue to get it approved for D.o deployment. If plans later change, the 'change request' can be updated, new implementation issues opened, etc.

Yep, that all sounds good.

So UX/security and other reviews would go on implementation issues then?

That's definitely my preference. The change record would serve as the central place to log that they've actually happened, though, along with a pointer to where. Because it's not at all reasonable for the deployer to have to read N sub-issues scanning NNN comments looking for the ones by Bojhan or greggles. :P

Very curious to see what Melissa thinks about this now that you and I are mostly in agreement. :D

I'm happy to find this. I want to read through this all. (making a comment so I can tag in my gmail, would be better to do something like #1621714: Allow to bookmark/favorite issues without abusing the Assigned field or issue tags, but alas I resort to making a "following" comment.)

updated issue summary to indicate ideation tool has already been split out.
the todos need clarification.