How do I navigate to the code repositories from the footer

[stevieflow]

As a user that knows where and how to raise issues, I want to raise an issue (such as #862 & #863)

From the footer there is plenty of details:

.. but none of these take me to the default "page" of the repositories - there are links through to the latest release (which is great) and the licences involved (also great) but not clear link(s) to help me understand where to create an issue

I don't know if that is in our design thinking for the footer, but it's a semi established mechanism in other IATI tools

dashboard

d-portal

obviously these are not the new footer - but the link to "create bugs" is there

I dont think the previous footer for the validator had this in either - so this is not an outcome of the design system implementation, I think (but opportunity to think this through - linked to IATI/design-system#40

[IsabelBirds]

I've also kept the FAQ about this in the new d-portal docs to ensure it isn't lost https://docs.d-portal.org/en/latest/general_faq/#faq-6

[jarofgreen]

As a user that knows where and how to raise issues,

Have we had a conversation about whether we want to support this or not?

I'm just aware that in other places we moved to try and reduce the incoming contact points and instead funnel people into Support/Zendesk.

If we do want to do this, we should make sure our process of reviewing and responding to all incoming notes from external people is good (ie better than it currently is, I think)

[stevieflow]

I'm just aware that in other places we moved to try and reduce the incoming contact points and instead funnel people into Support/Zendesk.

Yes, good point @jarofgreen

Maybe this is two things:

• where / how we point to the code repositories in a consistent way, in the footer
• where / how we route people to provide feedback (about the tool they are on).

@robredpath @IsabelBirds @siwhitehouse @emmajclegg could it be best that we route all contact through to https://iatistandard.org/en/guidance/get-support/ (which may then need some annotating), as this goes through to zendesk ?

[jarofgreen]

But if it is best to ....

route all contact through to https://iatistandard.org/en/guidance/get-support/

Then what are we trying to achieve with ...

where / how we point to the code repositories in a consistent way, in the footer

Just show off we are open source? Or do we expect developers to actually read code to understand things? Or even to contribute?

If it's just the some of those, is there a better way to achieve that? Do we even have an open source section on the IATI website, for instance?

Or is GitHub now so standard that developers might send us code stuff via issues they would never bother sending to a support address, so we should add it anyway?

(I don't have strong views which way we go on this, just wanted to be clear why we are doing this and if we do this I want to be clear we actually are checking what people send us.)

[IsabelBirds]

If users with strong iati knowledge come into the support desk, I encourage them to raise issues directly in github in future. Otherwise I am just forced to be the messenger.

The D-portal team have also fed back that it is useful to have the github feedback link in the footer.

"Less technical" users will be less confident with github and come to the support desk anyway.

[IsabelBirds]

Separately - I am constantly having to search through repos to find the right place to record things. Direct links would save me a lot of time...

[robredpath]

I don't think that there are so many people lining up to report bugs and suggest feature improvements to our tools that we need to create a particularly optimised solution, but equally we shouldn't make it hard - especially for ourselves.

I think it's good that we have a consistent and coherent "support" experience, which starts with a "support" link on a tool, goes to https://iatistandard.org/en/guidance/get-support/, possibly gets intercepted through some kind of UI to help people discover documentation (I've heard talk of a "support site"?), then to creating a Zendesk ticket if necessary. I don't think we should overload that flow with trying to handle all kinds of contact or interaction.

I am, separately, working up a mechanism to solicit feedback from people using our tools, which I think will start with a Google Form linked from the footer.

Our target architecture makes it harder for people who aren't super conversant with it to understand exactly where to raise an issue, as the output that you're seeing may be from a component that the tool displaying it has no idea about. I think we should encourage people to raise issues where they're seeing them, and then it's up to us to route them appropriately.

I think we can help people by ensuring that there's at least one link to a repo in the footer, and then by making sure that our READMEs help people feel confident raising issues.

[stevieflow]

We talked about this and think it could / should link into discussions about any "support site" and other ways we help people get their questions, queries and feedback to us and the community. @siwhitehouse will check and debrief on the "support site" initially

[siwhitehouse]

If users with strong iati knowledge come into the support desk, I encourage them to raise issues directly in github in future. Otherwise I am just forced to be the messenger.

The D-portal team have also fed back that it is useful to have the github feedback link in the footer.

"Less technical" users will be less confident with github and come to the support desk anyway.

+1 to this.

We could link this to the discussions about the support site and Holly should have something for us in the next week or two, but the idea behind it is for short items that help people "self-serve" password resets etc.. I'm not sure it is relevant/the place for people who want to raise specific issues about our tools.