Project Management

[ueen]

Maybe we can exchange some thoughts about this, because i feel some tension between the core team and sporadic contributors like myself. I want to make clear the enourmous effort you put in, and recognize that AP is a huge amount of work. At the same time my experiences with PRs for AP (i have also contributed to other, arguably smaller scale projects) has not been nice and is a major factor for my seldom contributing. I consider that i might be out of line and would appreciate your thoughts on this.

Communoicationwise it get a strong hierarchical feel between the core team and infrequent or new contributers. I know its annoying to repeat stuff or to have to explain things you know because of insides from your contributing history. I also get a strong german “every little detail has to be mapped out beforehand”-vibe. Which leads to endless discussions over even minor one-line changes and results in (overly) strict style requirements. All of which run againt a more creative, organic workflow that comes more natural to people like me.
I did a few minor UI/UX tweaks that i feel like turned out to be great and proofed really use- and impactful - but where preceded by hours of unenjoyable discussions and reformating to meet core team ideas/conceptualizations and style requieremnts.
I want to reiterate, that i see the huge amount of work all of this is and the effort you put in.

My feeling is that the communication could be enchanced and top-down requirement loosened to make contributing easier and more enjoyable, which in turn might lead to a better sharing of the workload (more contributing/-ers!) and quicker and better progress.

If i may say so, i see potential for a more effective project-management, especially in regard to communication. I think it is a vicous cycle, the core them (which seems to be @ByteHamster, @keunes, @tonytamsf, @Matth78) is doing so much, that communication can seem like an extra burden. But that might be what is keeping off infrequent or new contributers (i know this to be the case for me).
Effective Communication shouldn’t and doesn’t have to be a burden. It should and can help to share tasks more effectively and reduce unnecessary or duplicate work.

At the same time, in order to break this cycle, i believe the core team needs to let go of some felt responsibility and (learn more) to practice satisficing for solutions they didn’t work on and dont want to work on (and don’t have to).

I know this is a long statement and while i tried to phrase it esteeming/appreciative as well as contructive, i know this is a harsh critique of the status quo. So please read it carefully, be open, judge it fairly and be honest about what your answers are.

some backstory:
I worked for years as a part-time iOS/android dev in a startup. I recognize these patterns seeking to avoid, it goes like this:
do we really need this feature?
YES
It would be way to much work ;(
COME ON
But do we really really need that feature?
And so on.
It kinda works when I was working alone, if I said I’m not working on it, it’s not getting done.
For AP it’s different, firstly we work on (some)things we want to do ourselves and if I propose a PR I have already done the work and if I only give an idea for a feature I must hope someone is exited about it as well and takes over or do it myself. And there is a need for more effective communication the bigger the team grows. The hierarchy and style/structure requirements feel maybe to strong to only contribute from time to time to be, but I’m also just a part-time/hobby dev. But I feel like it would be nice to have a pool of people that do a little bit when they have time instead of the core team having to lift such heavy loads.
We need structure and style but it must be workable and the focus must remain on getting the code out. That requires discussion and communication and I feel there’s potential to improve, as well as sharing responsibilities and decision making more

[Matth78]

No worry but just to make things clear, I don’t think I qualify as a core contributor. I mainly translate french language and answers to others when I can. (Albeit for a long time now!)

As a non developer I also agree that it seems hard for other people to contribute to code. IMHO the main factor being a lack of stable contributors. Problem introduced by new features will need to be fixed by mostly main developer / maintener (ByteHamster) and so I understand it’s best to make things as simple as possible so it’s not too hard to maintain.

But I feel you and it’s frustrating to have features not implemented because ideas about how to do it don’t end with a consensus. (Let’s not go out of topic but episodes without subscription from user perspective I am looking at you!)

So yes it’s good to be aware of that and avoid such problems. Besides I remember a previous time when development was almost stall. So things are actually improving and I am sure if there was regular contributors things would get much better.

[keunes]

Thanks for bringing this up @ueen. Let me reply in bullet-point style:

• I agree that the way we work/approach the project is slowing down things. We need to improve this somehow.
• From our perspective, we’ve felt some times we’ve invested time in onboarding/helping/reviewing new contributions, without ‘return on investment’: we took the time to seriously consider someone’s contribution & give feedback, and then dead silence. We’ll want to avoid that as it’s demotivating for us.
• I understand that it feels like we’re taking a strong top-down approach. In a way it’s true (we have strong opinions & code/UX requirements), in other ways not (folks have suggested & pushed for things which we don’t really care about, and are implemented still).
• I recognise the attention to detail & lengthy (sometimes painful) discussions that follow from it. It’s in both my and @ByteHamster’s character. However, I’m not willing to compromise on the ‘quality’ aspect:
  • In principle I don’t care whether I worked on something or not. But very often I see UX issues/room for improvement. So I want to follow what’s reaching the product.
  • AntennaPod’s key goal is to be user friendly. Unfortunately many contributors don’t (care for) carefully considering UX. I’m sorry to say, but some devs come by & dump code. If we accepted all contributions as submitted, AntennaPod would be much less user friendly. (In my day job I listen to users & write up their needs, prepare specs, and review User Stories. Such structured needs-based approach helps ensure usability for a large group of users.)
  • As you said, we sometimes need to make choices. A project needs to have a vision and someone to guide the project towards it. For the moment that’s @ByteHamster and me. Yes, that means having discussions if we feel a contribution doesn’t comply with that vision. But with that, we get a better product.
  • I don’t think a ‘Let’s try’-based approach suits AntennaPod: a) we don’t have analytics, metrics to see if our trial works for users and b) monitoring also takes time & effort. Moving some UX check/discussion from before to after release means we risk analysis tasks being forgotten/not prioritised (i.e. risk of stuff remaining unchanged after complaints). New episode action (unfortunately) is a good example of it going wrong.
  • IMHO, based on the reviews we receive, our focus on UX and careful (yet slow) consideration is paying off.
• Not compromising on quality approach, we need to focus on time & communication.
• Frankly, some of the painful written discussions (in general, not specifically about you) could have been avoided by
  • being aware of what’s been discussed before (I know this creates a barrier to entry, but if you’re serious about contributing, a quick search and reading a clear FR can be expected - I’m thinking of #6229).
  • jumping on a call with us to discuss things (details are hashed out much easier & faster in calls than through writing)
  • sharing screenshots early & plenty to get feedback (I & many other community members cannot review UX based on code, I can only review wireframes, mock-ups or screenshots - often these are missing).
• We need to do a better job at communicating (e.g. in GitHub issues) what’s been discussed and decided, and is ready for anyone to pick up.
  • I’ve saved a standard reply about ‘implementation instructions’. We can add this to each first post in a GH issue, to point to the conclusive summary (example).
  • I’m thinking that rather than a ‘Needs: Decision’ label, we need a ‘Ready to implement’ label. That way it’s easier to see which issues can be picked up by one-time contributors - without risking that during implementation we realise it needs deeper discussion.
• @ByteHamster and I have already decided to, in an attempt to improve the time aspect, have a meeting every two weeks to discuss points that need hashing out and a conclusion. We’ve had the first one already (about the ‘New episode action’), and anyone is welcome to join in on future editions: Needs: Decision - AntennaPod UX discussions – AntennaPod
• We need to better explain what we expect from (one-time) contributors. I’ve proposed a ‘contributors docs’ area on the website.
  • The way we work (first problem & solution definition, UX agreement, followed by code)
  • Which channels we use for what (forum thread; GH issue, PR).
  • We should probably update the PR issue template, to add checkboxes through which contributor acknowledges first steps are OK.
• Guiding new contributors takes time (when you want to ensure quality). My ideal scenario is that we have a small pool of regular contributors (like yourself) who know the project (code style, UX approach, means of collaboration). That way the time both sides invest isn’t ‘lost’.
  • A specific sub-point are the code reviews. It would be great if some regular contributors can do initial code reviews of each-other’s work. That would hopefully free up some of @ByteHamster’s time.
• I would like to improve roadmap planning; determine with regular contributors what we’ll focus on. The major requests (multiple queues, improved tags, keep x episodes) are big projects and need considerable amount of time from UX, dev & code review. A roadmap helps us all spend the necessary time on the same feature in the same period. And helps to set expectations (we’re now working on X, so expect anything else to be slower). Curious to hear your thoughts on this.
• What I don’t really understand is that the best opportunity we offer for Effective Communication isn’t really used. We’ve been gathering online every month and there’s room to bring up stuff that you contributors want to pick up. Yet very often it’s just the three of us. What can we do differently so that this channel is used?
• We need to better think of which tasks we can ask others to do, and actively ask people to pick them up. That works: I’m very happy that @femmdi took over translations coordination and release notes writing, and that @loucasal has been writing some blogs for us (I have a couple of candidates in mind.)

Thanks again for bringing this up. Let’s continue this discussion

[ueen]

I don’t want to compromise on quality. But there process for contributors is too lengthy, this is a hobby and not a paid part-time job. The amount of time I want to put in are a couple hours a week max and we need to build the project management around that, not more clearly write out the requirements in guidelines for new contributors or what ever (even more for them to read). And it’s nothing personal but @keunes you’re not great of keeping yourself short

The call could actually be useful but the main work is done in PRs and code is what it’s all about.

[ByteHamster]

Sorry for my late reply. I had this thread in my bookmarks for quite some time now and somehow didn’t really have the mental capacity to reply. That’s probably also one of the main points of criticism - that I’m currently quite slow to reply to your PRs.

I think a reason for this is that we started with the discussions in the end of December, and I didn’t have too much time since then (Christmas, then a work trip (plus long hours of preparation), and now FOSDEM). I get around 10-20 AntennaPod related messages each day (GitHub, forum, email, etc). My inbox with things I wanted to think about is huge. If I don’t have a lot of time, I usually work on the easiest ones first - because with these we can bring AntennaPod forward in the limited amount of time. That’s also why I have focused on your queue locking PR first.

Working on the shortest job first is a known scheduling algorithm, which has the advantage of minimizing the average amount of time someone has to wait for a reply. Unfortunately, the scheduling algorithm can cause starvation, where the longest jobs don’t get attention at all because there are too many short ones. I think that’s what is currently happening for some of your PRs. In the end of December, we have started doing bi-weekly meetings to discuss open PRs. I hope that this can improve the turnaround time in the future.

[ueen]

Well my point wasn’t “turnaround time” but the very fact that everything AP hinges on mainly @ByteHamster. Like I really appreciate all the hard work, but it doesn’t look sustainable, or at least it creates a severe bottleneck.
My frustration is not mainly with this bottleneck but all the other things I wrote about and you didn’t even care to mention…

The queue lock is a good example, it was something a noted at the way side and thought it be an easy fix, now I’m supposedly required to learn a complete new thing: write testing logic. And this after I already put in hours of coding and even more of discussing. And this is a tiny change, big changes like home require so much effort (mainly for discussion) that it’s near impossible to do beside actual work and life. I don’t even get how you do it @ByteHamster and the truth seems to be: barely or just very slowly. I want to contribute but it is very difficult to do so and @keunes also said that this happens often with new/sporadic contributors. The bottleneck is playing a part here as well as management style and coding requirements.

My ultimate point would be: create a more contributer friendly environment that then could ease the bottleneck (more people to share the load/tasks) - but this has to be reflected and enabled by the project management!

Also I’m again spending way to much time on discussing instead of coding which proofs my above points.