arthurcoudouy

My primary guess would be that it's easier to earn your first dollars with fans vs. with B2B sponsorships (or even with retribution from platforms like YouTube). Also, I don't really understand the term illusion in the image if someone could help. 5% conversion from content consumer to "paid fan" does not seem that low

It may be a stupid question but why did you strike through 2022 and 2023? Did you create it in 2022 and maintained it since or is it a recent project?

Did you build this to solve a specific issue?

I can relate. I've had trouble finding a well-designed screenshot tool for Windows, while Mac users have plenty of options. It seems like most local-first apps are built by indie hackers, who are more likely to use Macs over Windows machines. On the other hand, it seems like startups tend to focus on developing web-based applications for wider distribution.

Apologies for my late answer by wanted to circle back to thank you, you answered most of what I was looking for.

I'm trying to know when specific subjects are being discussed.

Thank you for the suggestion! Will do

I did reference this in the article.

> The DORA (DevOps Research and Assessment) framework introduced some metrics to track team flow, such as deployment frequency, which measures how frequently an organization successfully releases to production, and lead time for changes, which measures how long it takes a commit to reach production. If you're interested in the DORA framework, we published a dedicated article on How to implement the Four Key Accelerate DevOps Metrics.

I can't agree more with you. I tried to sum my thoughts in my first reference

> One of the most common myths — and potentially most threatening to developer happiness — is the notion that productivity is all about developer activity, things like lines of code or number of commits. More activity can appear for various reasons: working longer hours may signal developers having to "brute-force" work to overcome bad systems or poor planning to meet a predefined release schedule.

The SPACE framework is not about measuring quantitative data only. I feel the need to explain how certain metrics might be interesting, but rather to identify key issues or unexpected events during engineering sprints. Without data analysis, you would not be able to understand why there is a drop of productivity during certain periods, and usually, those drops were created by the management (too many meetings or lack of follow-up)

I'm personally not a huge fan of collecting quantitative data to evaluate engineering productivity. The context of such metrics is usually more important that the data itself, meaning using some discrepancies in your results to identify business needs or issues. When I work with quantitative data, I try to find pattern rather than analyzing the data iself (why do pull requests last longer on Monday afternoon? do we have too many meetings there?..)

I've got a couple of questions: Do you plan on developing a no-code interface soon? Before learning to code, Stripe on my own landing page was a no-go. Do you help in completing the integration after your own or should I do a proper Stripe integration after Plug?

Congrats on the launch anyway, I'm convinced that your solution makes sense for early stage company. You'll have to provide more value in the future to keep enterprises in the long run I guess.

You can find the first version of analytics here : https://app.axolo.co/leaderboard/axolo-co

This is a work in progress. We iterate with our beta cohort to build the panel they want. In addition to the information you can see there, we let you know if we detected potential risks in your code development process (pull requests merged without any review for example).

If you're interested in knowing more about our roadmap concerning the analytics, we might build a separate app for analytics only.

During the pull request lifetime, only messages from Github are sent to Slack. This enables our users to use Slack as a center of notifications and let them have more synchronous communication if a conflict appears (if they want to). The other way is only to save the Slack communication as Documentation for future context if the pull request needs to be reviewed again in the future (after it has been merged or closed).

Github's conversations are fine until a conflict appears, when two opposite point of views are confronted, what usually happens is to jump on a call or continue the conversation in Slack. As most of the conversation are still in Github, we do not feel that we split the conversation but rather use Slack as a way to let them stay top on mind if your review is required.

Moreover, there aren't only comment's notifications but Github Action, deployments and soon more that takes place in their respective pull request channel. Some people are more likely to use Axolo as a new way to handle code review conversations, some other as a new center of notification.

If you have other points of friction in mind, please do share them, that helps us better identify potential issues!

Unfortunately, Slack does not have that level of granularity yet, so the permissions are given to all public channels. But we only interact with Slack saving the ID of the specific channel we create, we do not store any information from other channels.

That's not working (you can't save it) anymore but you can create your own here..! https://app.axolo.co/register/axolo-co/createyourown

Thank you for taking the time! Axolo is still in beta, sorry for the fews bugs you might encounter. Reach out when you find some, we'll always be in alert mode :)

Thanks! We're still working on developing a great experience on Github, we'll look into more integrations in a few months. Our issue will be to decide on Gitlab vs. Bitbucket first.

Thanks for this topic! As we're only working on Github for now, I can't speak for Gitlab. The shift for a code management tool to become a collaboration tool is a giant step. Embedding the only information regarding interactions around code reviews in Slack was a small step to centralize everything in one place.

And one thing we're sure is that our current users are Slack lovers - if you're trying to spend less time in Slack, I'm 100% convinced that Axolo is not right for you!

Today, what we provide is a way to handle code review without context-switching between Github and Slack/calls. Axolo helps to unstuck dangling pull requests in centralizing notifications in one place and let them be top of mind as a "to-do list" in your Slack.

> Where do you see the difference in a private message to someone that says "hey, can you check out this Pull Request?" and a Slack channel that automatically says "hey, can you check out this Pull Request?"

In case 1, you need to write in dm to your reviewers and ping them again if you did not receive any news. In the other case, Axolo will do it automatically and remind them about it. We believe it's easier to have specific channels because if you're requesting a review at the same time as your reviewer might, different conversations will happen in the same dm channel. And that's only regarding someone asking someone else for a review, there are other informations that have importance in your worklfow regarding pull requests (Github actions, comments & reviews)

Referring to the lack of time, we think that might be addressed in motivating engineers do more code reviews. We try to foster better practices with our "leaderboard" but we're still iterating to find the best answer.

> What about cases where any one random reviewer (or several) is needed from a larger group of people? Does everyone get paged in?

If you select several reviewers and only one is needed, that'll ping the group of reviewers. That's not something we recommend, we think that one should use a random algorithm to select a specific reviewer if you prefer to select a group of people (https://docs.github.com/en/organizations/organizing-members-...).

> Or cases where a single reviewer is assigned to multiple different reviews? This becomes a DDOS attack on the human attention span and has the potential to create disorientation more than anything.

Instead of having notifications from Github, emails & Slack, we believed that it's easier to manage notifications when they come from only one place. When you're working on something, notifications should be muted. Axolo in Slack works as an "inbox zero", you should focus on your code and come see where your review is needed in a dedicated time.