# Issues or whatever

## Jira stories lack structure and definition.

**First: I am [guilty](https://ebpp.atlassian.net/browse/INT2-317) of [this](https://ebpp.atlassian.net/browse/INT2-349), as well.**

Some titles have the word "UI" in them. Some have ", UI" at the end. Some (that Chris and I have created) have "UI - " at the beginning. So differentiating what is a UI ticket to pick up is difficult.

Inside of stories, there is rarely adequate information. One or two sentences and a screenshot of a component in Figma is never going to be adequate.

The stories I have authored, as seen above, are not structured either, but definitely do not lack detail!

This, though, is an improvement from when I first started here and stories rarely ever contained any information whatsoever and relied upon developers to recall what was said in grooming.

Here's an [upcoming story](https://ebpp.atlassian.net/browse/INT2-261) that is pretty underwhelming. (Luckily, I understand enough at this point that I have intimate knowledge how this will work, what it will do, and how I will implement it lol.)

## Developing UI before services are complete.

When I create a component that depends on an endpoint, I have to have a second story to return to that implementation later and make the service call align with what the final service ends up requiring from me and what it returns.

Services are rarely finished when I am working on something, and we have observed that when services are in development, they are constantly changing. The data they require, the data they respond with, the urls, etc. Chris and I have agreed that we can't trust any of it until it is "done".

Furthermore; there is some weird "r1", "r2", etc stuff going on where there are endpoints created for us to consume, we consume them, and they are later being deprecated in favor of newly created endpoints for the current "rX".

I don't know why this is happening. I would think that the service for POST "/foo-bar/what-ever" would be maintained as functionality evolved. But, instead, it seems they are creating release specific endpoints.

It is quite confusing and has me writing cautious code due to uncertainty.

## Confusing and inconsistent Figma references.

In the original stories for the [RescheduleButton](https://ebpp.atlassian.net/browse/INT2-168) and [CancelButton](https://ebpp.atlassian.net/browse/INT2-170) components, I believed I was meant to create 2 different button components. (Especially because there were 2 separate stories.) It was not clear that there was only 1 button, nor what the exact requirements were for that 1 button.

In my [follow up ticket](https://ebpp.atlassian.net/browse/INT2-170), in which I documented a bunch of things to be sure we were on the same page and I was doing the absolute correct work expected of me, you can find a ton of Figma references to the same component. -- A lot of these references show different states / variants that were not explained to me or even brought to my attention in Jira stories.

Often times in Jira stories, there is a screenshot taken from Figma (or, sometimes, a link to the Figma), but the actual UI requirements for the component are typically missing. If I go into Figma, myself, to figure this stuff out, it becomes very easy to become unsure about what I am doing, because there are so many different versions of component designs.

I am about to take on a ticket to go back and add error handling to a component, and another ticket to go back and disable some form fields in a different component. These were agreed upon requirements from the get-go, but were not conveyed to me, and I had to make assumptions by assessing designs.

Stories **should** be detailed in what is expected, as far as functionlaity goes, and also about the styling of the component, different states of the component, etc.

## Stories authored with confused concerns.

It is common for stories pertaining to my component library to have descriptions that list what should happen in the Apply application. Sometimes it mentions how "when a user has done X and Y", but this is all irrelevant to my work.

I am not building components for Apply. I am building components for distribution to an infinite number of AIO applications. I need no introduction to how the user arrived at my component, nor do I need to know what the user will do when they are finished interacting with my component.

### Example

In [this instance](https://ebpp.atlassian.net/browse/INT2-87), you can see that the story references the placeholder map being used in the InterviewDetails component that lives inside of the Apply application.

The details for the story are phrased as though this ticket is, in some way, related to the Apply application, but it is not. I am not replacing the placeholder map with a fully functional one, I am ripping the entire InterviewDetails component out of Apply and putting my own component, abstracting all the logic and data so the Apply developers never even need to think about what is going on there.

coltoansfhj aieghi