Adding @pfrields and @ryanlerch too, since they might have ideas for "Fedora Magazine metric wishlist" to throw into the ring.

@skamath @dhanesh95 In today's meeting, we talked about the WordPress REST API as a way to accomplish this. Do both of you think it's a realistic goal to work towards at our FAD?

@jflory7 @skamath We may require more than one 'FAD' to accomplish our final goal. If that is acceptable, then we can break this ticket down into multiple modules and work on a specific set of modules in our upcoming FAD.

Thoughts?

@dhanesh95 I am +1 to dividing this ticket into smaller milestones and identifying critical ones for the FAD; could you lead the effort on rounding this up?

We can research and learn now what this task looks like and what effort it requires. At the FAD, we can advance on implementing it and get feedback from others.

@jflory7 Sure. I'll break it down into smaller milestones and reply here once done. Just one question - the description of this ticket mentions everything that needs to be achieved, right?

Discussed during 2017-12-11 meeting.

Reaching out to Magazine team

@dhanesh95 noted some difficulties of what data is available to us via the WordPress REST API (especially with article statistics, like view count). He is going to reach out to the Fedora Magazine team before next week's meeting to get their feedback on helpful data / metrics we could collect, based on the info we have now with the REST API.

Adding this to our meeting agenda for follow-up next week.

Discussed in 2017-12-18 meeting.

This ticket is pending the previous action item noted above. We decided in the meeting that @dhanesh95 can add this ticket back to the meeting agenda when he needs feedback from the team or wants to have a group discussion.

The Jetpack statistics engine, provided by WordPress, already yields a number of metrics including the ones noted in this ticket. I don't think we should duplicate that functionality in yet another codebase. Can someone explain how this concept differs substantially?

@pfrields Comment-ninja'd. I replied to the Magazine mailing list post with some background a minute ago, but will repeat on this ticket too, so the motivation is better documented.

The specific goal is look into fedmsg integration via the WordPress REST API. Ideally, this allows us to automate the creation of helpful, insightful metrics about the performance of the Magazine, both to help the editing team and also help other teams in Fedora understand what our user base is interested and engaged in.

For example, I'd be interested in seeing our best-performing categories and tags, to help evaluate key interest areas. Other ideas are the usual metrics @ryanlerch and you put together at the end of the year. By building fedmsg integration, this also allows us to incorporate the Magazine into a GrimoireLabs dashboard (more info in #114).

It would be helpful to have the "metrics wishlist" either as a comment in the ticket linked above, or to be listed here on the mailing list. This will support one of the discussion topics at the CommOps FAD at the end of the month.

This makes a little more sense. I wanted to ensure we're not re-implementing what we already get for free. :wink: Typically we are focused on pageview metrics. Per tag may be tricky because I don't think we're consistent about that. Categories are more consistent and hopefully stats would be more accurate there.

@dhanesh95 noted some difficulties of what data is available to us via the WordPress REST API (especially with article statistics, like view count).

Linking the correct WordPress REST API documentation here:

https://developer.wordpress.com/docs/api/

Discussed in CommOps 2018 FAD

Summary

We decided to target only the WordPress platform given that we have a lot of other tasks on our plate. We discussed the end goals and the ways we can achieve them.

Goals

• Insights into what users are interested in and looking for
  • Help technical teams in Fedora measure impact of their work
  • Drive marketing focus towards areas of strong engagement (supporting Mindshare)
• Writers / editors: Provides helpful feedback to change or continue messaging that's successful
  • Assist editing teams of Mag / CommBlog in focusing content in a specific direction
  • Grow community of writers to the Fedora Project
• More easily game-ifies a significant area of contribution
  • Encourage healthy contributions
  • Keep up the enthusiasm

fedmsg integration

1. fedmsg requires an event to be published after a certain action happens. This requires us to set up a POST webhook (in PHP -_-) which is called after every notable action takes place.
2. A way to do this is editing the existing RSS feed to include the FAS ID of the user. This will be recognized by Fedora Planet and a fedmsg event will be pushed.
3. Another way to do this is building a middleware which will handle all POST requests from WordPress and will publish a fedmsg event.

P.S:
I also came across Huginn which is an Open Source alternative to the popular IFTTT service.

Discussed in 2018-03-19 meeting.

@dhanesh95 is finishing research on options above to put together a final proposal to move forward with the integration by our next meeting on Monday, March 26, 2018.

Huginn may enable us to implement fedmsg support for WordPress without writing our own plugin. This may be a part of the proposal depending on what @dhanesh95 finds this week.

Fedora 28 milestone deadline

This issue is tagged for completion during the Fedora 28 (F28) milestone. The F28 milestone ends on Tuesday, May 1, 2018. This issue will be bumped to a future release cycle.

After a long time, I made some progress on studying how Huginn works and if it will help us achieve the goals we had set. Sorry for the delay.

Goals

Insights into what users are interested in and looking for
Help technical teams in Fedora measure impact of their work
Drive marketing focus towards areas of strong engagement (supporting Mindshare)

Writers / editors: Provides helpful feedback to change or continue messaging that's successful
Assist editing teams of Mag / CommBlog in focusing content in a specific direction
Grow community of writers to the Fedora Project

More easily game-ifies a significant area of contribution
Encourage healthy contributions
Keep up the enthusiasm

My Findings

• Huginn is an extremely helpful software that can give us the flexibility in performing the operations that need to be performed. It has a host of 'agents' (for a host of services) that listen to events and process them as per our requirements. However, there isn't a agent that can be used with Wordpress or specifically with the use-case of this ticket.
• Every time an event is performed on Wordpress (publish post, comment, like and so on), an 'Action' is launched for the event. This can be used to to write custom functions which send a webhook to a given URL.
• To implement such a functionality, currently there is only one Plugin available in Wordpress which is actively maintained - WebSub/PubSubHubbub.
• If relying on a plugin is a matter of concern, we can write our own functions in a child theme. This answer on StackExchange gives a very good example - https://wordpress.stackexchange.com/a/269691
• As mentioned in an earlier comment, fedmsg requires a POST webhook which publishes an event.

Considering all the observations, the following approach to implementation, probably not the best, could prove to be easiest and the fastest.

Suggested Approach

1. Forget Huginn

• Wordpress will allow us to send POST requests to any URL. Given it's complexity, having Huginn to just listen to these requests is a huge overhead.

2. Create new child theme and write custom functions

• As mentioned above, we'll create a child theme and write our own functions in PHP to send POST requests once an event is performed.
• Using a plugin may restrict us to the extent of it's support for actions. Also, if a plugin is retired, migrating to an alternative or replicating it's functionality will be a time-consuming and difficult task.

3. Write a custom middleware (mostly in Python)

• Using the Flask-RESTful framework, we can write a small middleware that will receive the webhooks from Wordpress, process them (if required) and publish them to fedmsg.
• The reason for this additional layer is to make sure both the ends don't break. Over a period of time, there can be significant changes to the APIs on either the fedmsg side or the Wordpress side. Having a middleware can always prevent things from breaking. For eg: If the API parameters for fedmsg change, publishing events to fedmsg will break. A middleware can handle such cases and store the requests on it's side to try again later.

To implement this approach we may need a server to run the middleware. I'm unaware of the process to request for a cloud instance from Infra or even requesting one is at all possible. Maybe @jflory7 can shed some light here.

This may not be the best approach to tackle this ticket and I'm open to more suggestions on how we can make this better. If anyone here has any prior experience with Wordpress development, it would be great to hear their thoughts too.

Cheers!

Hi @dhanesh95, thanks for putting in the research work. I am CCing others ( @bex @kevin @pfrields @ryanlerch @puiterwijk ) for their Infrastructure / Design input and the best process to follow.

@dhanesh95 said…
This may not be the best approach to tackle this ticket and I'm open to more suggestions on how we can make this better. If anyone here has any prior experience with Wordpress development, it would be great to hear their thoughts too.

Some of these areas are outside my area of expertise, but I hope one of the CC'd folks can review this proposal and offer more feedback: https://pagure.io/fedora-commops/issue/108#comment-520486

@dhanesh95 said…
2. Create new child theme and write custom functions

This step seems trivial, since we already have a custom theme, fedora-communityblog.

@dhanesh95 said…
3. Write a custom middleware (mostly in Python)
To implement this approach we may need a server to run the middleware. I'm unaware of the process to request for a cloud instance from Infra or even requesting one is at all possible. Maybe @jflory7 can shed some light here.

There is a process to request an unofficial cloud instance for hosting things like this. However, its trajectory also depends if we would want it to live in the Fedora production environment or in a cloud instance. I feel like it makes more sense to put in the effort to set it up and run in production, if possible.

So, a couple of things I'd like to note here...

1. I am not sure how much sense it makes to fedmsg enable metrics. We would need to be very careful to anonymize them (which is difficult to do) and if there's really only a metrics dashboard or the like operating on them, having tons of metrics fedmsgs seems like a waste.

2. I see that jetpack has plugins/a plugin framework. Perhaps thats worth looking into rather than an new big app?

3. Finally, our openshift setup is coming along nicely, and I am not sure how much @puiterwijk would scream, but we could think about moving magazine and community blog into openshift from the infra private cloud. The reason I mention that is that then we could use the built into openshift metrics, which are pretty complex and nice (but I am not 100% clear on what you need). Note that we only have that setup in staging yet and it still needs persistent storage, but hopefully that will happen after beta.

When @dhanesh95 has time to look into this next, we'll bring it back up on the meeting agenda.

Unfortunately, there has been no progress on this ticket since my last comment more than a year ago. The past year has been busy and I don't see the situation changing anytime soon. As a result, I'm dropping this ticket and I encourage current active members of CommOps to take it up.

Discussed in 2020-08-08 Fedora Nest metrics hack session.

We decided to close this ticket as stale, given the three years of attempts on this ticket. We could all agree it is a super idea and would be great to have, but CommOps does not have the resources to pull this work off.

If this work really is valuable and worthwhile, one possible way forward would be to drive this at the Fedora Council level and work to identify engineering talent inside Red Hat that might be interested in helping lead this.

But for now, someone else will have to pick up the torch. We are going to move on to new things and let this one go.