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