Site inconsistency in lists

[VeselinaPeykova]

1. Answers - only the title name is displayed:

2. Blogs - title+a few words from the blog opening sentences (no images or video), which sometimes don't make sense:

3. Coffee Corner- title+ whatever you can think of:

In case you are wondering - this in one article in Coffee Corner with a screenshot from Q&A and some text, which takes over the whole page.

I would really like to see some consistency in this aspect by default (if browsing anonymously) and a profile setting, which lets me choose the way I want to see the content displayed.

[VeselinaPeykova]

There are so many items high in the priorities list post-launch, I hope that this one is not considered more important than the tags explorer and the fully functional site search.

[former_member181891]

We have several high priority categories, as you mention.  Please look for a blog post from soon detailing this.

Best,

Jamie

[agentry_src]

Hi Jamie,

So who decides the priorities and perhaps more interesting, who has been setting the priorities on bugs? 

Regards, Mike

SAP Technology RIG

[former_member181891]

The topic leads on the business side + the technical folks on the IT/dev side collaborate to prioritize based on feedback and criticality of bugs (e.g. is something completely broken/inaccessible vs. a minor nuisance).  We examine based on impact (# of users affected + effect on usability + users' business need + technical feasibility) and make a determination together which bugs are most critical to tackle first.  No decisions are made in a void.

Best,

Jamie

[agentry_src]

Hi Jamie,

Nor are they made public for review, are they?  Feedback loops are important for control circuits and collaborative efforts.  There have been a whole lot of people doing the testing and providing feedback.  Without feedback loops, randomization enters and resources are wasted on minor and cosmetic items without fixing the critical items. 

The critical items are being identified by the largely volunteer group of members.  The setting of priorities should also involve a feedback process involving those selfsame volunteers who have been identifying the issues all along.   These people can provide a lot of valuable insight into why one bug is more important to fix than other bugs. 

Your team setting the priorities for bugs seems to have left out the actual members who identified the bugs in the first place.  Why does that seem to be the case?

Regards, Mike

SAP Technology RIG

[former_member181891]

I don't agree that we've left out the members who identified the bugs, but that doesn't mean we don't have room to improve. 

That said, in an agile environment, we cannot operate on a consensus vote for every prioritization decision (and I'm pretty sure you don't have the time, with your day job responsibilities, to attend all the strategy and decision point calls we're involved in, AKA our day job). 

I think of it more like a representative council, where we are doing our best to represent our constituents (the users) in the decisions we have to make on a daily basis.  For the bigger decisions, we come to the community for consensus, but for the day-to-day operation, we have to be able to make those decisions ourselves with the confidence of the community.  I understand that the community's confidence might be shaky going into this big rollout, but like I said this morning, we are all working towards the same goals and objectives here.

If you have pragmatic ideas on how we can do better, I'm always open to improvement. 

Best,

Jamie

[audreystevenson]

Let's also not forget the Strategic Advisory Council (of which you are a part) and the Reputation Advisory Group, both of which are regularly asked for feedback and input on criticality levels. Their voices have helped us increase priorities of certain changes needed.

[agentry_src]

Hi Jamie,

Post a list of reported bugs with a priority (Low, Medium, High, and Very High) with roughly the same evaluation criteria as we use for tickets published in a blog with comments allowed would be a good start.  That would allow feedback from the members who have done much of the detailed testing and bug reporting.  Feedback does not have to be during the assignment of a priority.  Often times it is easier to run something up the flagpole and see who salutes instead. 

But as you can see from a lot of recent posts, there are bugs which people consider critical and others which are a lesser concern or which have some sort of workaround.  Comparisons can be made.  For example, Search not returning a comprehensive result is set  to a status of Very High.  If a custom Google search is available which does the job, then a workaround exists and the priority could drop to High or Medium.  SSO not working when navigating is High or possibly Medium, not Very High.  Access is not limited by SSO not working, it is just really annoying.  Without fixing it, you might drive people away in frustration, but probably not very many.  An inability to perform necessary Moderation tasks, such as releasing moderated items should be Very High, but the new Alert Categories should be High or Medium (I prefer High, but that's because I get really tired of typing Necromancy). 

Anything whose status with which people disagree can be reviewed and commented upon.  Changes can then be made as a result.  This is a workable model, but it depends upon transparency as the first step.  Depending upon how accurate the priorities are set, there may only be some minor tweaking.  If the priorities are grossly out of whack, the setters can learn from the feedback and do a better job as new bugs arise. 

And so on...

Regards, Mike

SAP Technology RIG

[agentry_src]

Hi Audrey,

Yes, I am a part of the Strategic Advisory Council, but meeting monthly for an hour with an agenda driven by the SCN Administration team is not a very flexible means of getting detailed feedback on those bug fix priorities except in a very general sense.  It also does not include many who are doing the most detailed testing.  I also see a very optimistic view of the new environment which I and many others do not share.  Too many things are going to be addressed in the future. 

There have been improvements.  SSO works much better than it did, but is still flaky on occasion.  Track in Communications type of functionality is still not present.  Search is also better but still does not work very well on phrasing (like primary tags).  Still lots of wasted white space in CTPs, Primary Tag tools are very limited and not user friendly, such as following primary tags.  But in truth, we still need another round of beta testing.  Not that we are going to get it, but many of us think much more should be fixed before go-live.

Regards, Mike

SAP Technology RIG

[former_member181891]

Was there something, for example, in Oliver's blog post about priorities that you think was "grossly out of whack"? 

Debating prioritization of every individual bug on a blog is not, in fact, a workable model (we tried that in beta -- I think we can all agree the bug list and feedback list became not very useful, as it was unfeasible to keep current).  We will maintain a public known issues list after launch, which will focus on the most impactful items (like the ones you highlighted).  However, we will not publish a list of every single bug reported.  If you've worked on any major rollout, you know how impractical that is.  Bugs move up and down in prioritization all the time, depending on the most current information available.

It is impossible to keep such a list current in our rapidly evolving environment, as it's a manual duplication of our existing internal bug management system.  An outdated list doesn't serve the needs of anyone, particularly our end users and, frankly contributes to more resources being drawn away from actual productive work on implementing actual improvements when we get stuck debating outdated information. 

We are committed to transparency and ongoing collaboration with our users.  This is not lip service.  User-driven development is something I believe in at the very core of my professional ethos.  As a part of that commitment, we will not create another situation where our users feel like their feedback is just falling into a void because they are not getting updated information.  Rather than investing our time in managing a huge, ugly, quickly-outdated list of every tiny bug reported, we are refocusing on providing more frequent and informative communication, drawing more clear connections between bugs and feedback items that have been reported and those implemented, and more information about future development plans.

Jamie

[agentry_src]

Hi Jamie,

One major item in Oliver's blog post and something implied by his list of features and bug fixes illustrate my frustration on this topic.

No mention of any efforts to validate or incorporate the short term fix of the Wiki in any of his comments.  Redirects are sending people to the Archive rather than the wiki is a bit of an issue.  Some items there relate to a lack of tagging, no updates to the product structure (new locations for product or topic related content).  In the rush to put out the new system, our members were required to recreate in the wiki and repair hundreds of some of the most popular and well trafficked pages in less than 3 weeks.  Despite that some redirects are not sending people the wiki or even to the old Jive doc (https://wiki.scn.sap.com/docs/DOC-55879, https://wiki.scn.sap.com/docs/DOC-55880, https://wiki.scn.sap.com/docs/DOC-54054 as examples). 

"The same is true for the SCN Wiki, which is a great source of valuable information and didn't get the necessary attention in the past. Therefore we will publish this year a long term roadmap this year that provides more detailed insight into which features we plan to deliver in 2017."

It does not seem to be getting that much attention in the present either. 

The implied problem is the list of bug fixes and features lists any number of items as features which should be bug fixes.  Features by their very nature imply optional implementation whereas bug fixes are mandatory,   So why would any of the following be listed as "features" when they should be considered bugs:

• (Activity Stream) SSO implemented: Activity Stream now automatically signs you in without additional action in case you are already authenticated in Blogs or Answers (SOC-3638)
• (Tag Pages) Community: "Follow a Tag" feature (SAPONEDX-8725)
• (Blog Migration) New blog migration done that includes all blog content till August 15th (SOC-3602)
• (Blogs) Introduced action menu with possible actions like 'View my posts' or 'Write a blog post' (SOC-3560)
• (Blogs) SSO implemented: Blogs now automatically signs you in without the need of any user action in case you are already authenticated in Answers or in the Activity Stream (SOC-3637)
• (Answers) SSO implemented: Answers now automatically signs you in without the need of any user action in case you are already authenticated in Blogs or in the Activity Stream (SOC-3367)
• (Archive) New Date format has been added to Archive pages to allow correct indexing for Search on HANA (SOC-3097)

I disagree that the transparency is already present.  Further what is being presented is not a coherent picture of what is being worked on until after the fact.  And while the list of bug fixes with the number associated allows cross reference, breaking it out into separate documents is making it more difficult, not simpler to understand what the bugs are that have been fixed. 

Perhaps our ideas of what presenting a clear and coherent picture of the priorities are a bit different.  By the very nature of after the fact reporting, there is not a feedback loop. Oliver's post refers to a variety of topics and acknowledges the needs, however nowhere is there clear presentation of what is being addressed in which order. 

"Also, based on your direct feedback we identified the most important topics to fix and improve between now and the year's end."

The long list of topics in the Community Roadmap do not give many specifics, so are they all going to be addressed equally?  Do you give more weight to fixing the Activity Stream or creating Notifications by Email?  If you fix the Activity Stream, does that lower the priority for the Email Notifications?  They are both addressing the same member need of updated information.  My feedback is that Activity Stream is much more important.  While Activity Stream can functionally replace Notifications by Email, the reverse is rather cumbersome for those active members and Moderators who monitor a lot of content.  Emails would just fill up the Inbox without providing any real benefit. 

Regards, Mike

SAP Technology RIG

[former_member181891]

Great feedback, Veselina, thanks!  I agree, the UI needs to be unified across all the applications and it's something that is high on our priorities to align post-launch. 

Best,

Jamie

[jcgood25]

Adding tag

[Steffi_Warnecke]

I would definitely prefer the "just the title" approach from Q&A. It's clearer readable and reduces the scrolling.

Right now CC looks reaaaally confusing.