Re: Issue descriptions library vs. filling reports from scratch

Vlad,
I am curious.
How do you feel issues are reported to companies from end users?
Additionally, how are you defining typical here?
After all, in theory at least, there are many ways for an individual 
embodying a disability to accommodate.  As I say often, a shared label 
does not a shared experience make, at all.
Team implies insiders, who   may have been provided with technical 
baseline solutions as insiders that are not available to the end users, 
the general public, or  those actually using the  site or tool in 
question.
So, again, I am interested in your stance and definitions here.
Best,
Karen Lewellen



On Mon, 22 Jul 2024, Vlad Kolpakov wrote:

> Hi all!
>
> Arguably, it is more efficient to pull issue descriptions of typical 
> accessibility issues from descriptions library versus filling in every bug 
> report from scratch.
>
> I think that consistency across different projects is an additional benefit, 
> as well as having a shared understanding within the team.
>
> On the other hand, I see that information in such fields as Summary, Steps, 
> Actual behavior and Expected behavior may differdepending on the context in 
> which the issue was found. Even remediation recommendations will often need 
> to be adapted to a specific project which means additional time for editing. 
> So, I can understand folks who think that writing a bug from scratch may take 
> the same time as finding the same bug in the library and adapting it to the 
> context.
>
> Personally, I'm a boilerplate content fan. But given the above, I'm a bit 
> hesitant whether it is a good idea trying to promote the same approach to the 
> team. :)
>
> Please advise: in terms of efficiency, does that make sense developing and 
> maintaining the issue descriptions library or not?
>
> Thanks in advance!
>
>
> -- 
> Best,
> Vlad
>
>

Received on Monday, 22 July 2024 16:32:45 UTC