User Centered Design / User Research and Domain Driven Design / Domain Modeling go neatly side-by-side and can be done in parallel: As you acquire domain expertise from your stakeholders you draft your models. You then present the models with “Is this how it works?” and refine further. You can take your stakeholders, even when non-technical, along the way during the entire development lifecycle of FedeProxy.
Your emerging themes might be indicators of what should be your core domain(s). You collected the right stuff, i.e. their actual current domain knowledge. If there’s most interest for federated Issue Tracking that might be the way forward. In any case a good MVP can be build around this, along which you can then further extend later on.
Wrt the workflow example you mention, it is questionable if it is part of the domain. Probably not. The copy/pasting of issue URL’s is a necessary evil dictated by the tool, as you say a UX improvement, not a domain concept. But the action indicates a domain relationship that exists.
Interesting to consider is that in the domain of Software Development the Code Forge is not really a domain entity, just like in ECommerce the Webshop is not necessarily an entity. The Forge is just a tool to tie things together (it is more an application domain concept, rather than a real-world business domain concept).
In Ubiquitous Language (not really, because I’m typing quickly, just making this up) you may have:
- Stakeholder expresses Needs
- Designer analyses Needs
- Needs translate to Features
- Needs determine Requirements
- Features determine Design
- Requirements determine Design
- Developer creates Code.
- Code adheres to Design.
- Code matches Requirements.
- Code implements Features.
- Tests verify Requirements.
- Tests demonstrate Features.
This list gets long pretty quick, but sentences are very simple English and can be easily shown in a basic diagram with circles and lines. We haven’t mentioned Issues yet…
- Developer tracks Defects.
- Designer tracks Features.
- Issue documents Defect.
- Issue references Code.
- … (etcetera)
As you extend this model you’ll notice your diagram circles are harder and harder to present visually in an understandable way. At that moment you can start looking at possible logical groupings that represent a subdomain. You can then take them out and now have 2 diagrams with bounded contexts and a context map.
Back to the mention of workflows… What are the Requirements of Software Development? They can be expressed in terms of Productivity, Quality, Maintainability, Extensibility, etcetera. Creation of a piece of software is usually packaged in a Project and here we enter a Project Management domain. Planning and Milestones, Releases come into play, and they too relate to Issues. We may have concepts that encompass multiple Projects and their management procedures, maybe called Development Method.
And - a better alias for workflow - we have Processes that are subject to a (Development) Lifecycle. While FedeProxy need not deliver features that target this, it is valuable to look how your Issue Tracking domain fits into this bigger picture. Productivity for instance depends in large parts on streamlined Process, while Quality involves tracking Defects and Requirements throughout the Development Lifecycle.
(Don’t want to make this too complex, but FedeProxy is a consumer of this domain, as you develop yourself, i.e. dogfooding-galore)
In summary all this is (or can be) very intuitive, and you can talk it through with your domain experts. By no means do you have to transfer domain concepts 1-to-1 to abstractions in code. That’s a secondary choice. Key is that you now understand the domain very well.
Finally - unrelated - an interesting PoC project I found by the devs of Flockingbird - a federated LI alternative - a project called Roost. In it they apply DDD/CQRS/ES to a certain extent.
And another AP project TrustBloc Orb by @troyronda (welcome Troy 
) use BDD in their feature tests, e.g. for ActivityPub.
Behavior Driven Design tests are a great match for DDD, as you can write them in ubiquitous language in ways that your non-technical stakeholders can still understand. Now they too can verify that the solution matches their needs, and continues to do so.
(Update: @dachary though this may seem very OT wrt FedeProxy the following article mentions a high-level general problem that faces FOSS and its community, where FedeProxy might somehow play into as well)