Technology

59414 readers

3374 users here now

This is a most excellent place for technology news and articles.

Our Rules

Follow the lemmy.world rules.
Only tech related content.
Be excellent to each another!
Mod approved content bots can post up to 10 articles per day.
Threads asking for personal tech support may be deleted.
Politics threads may be removed.
No memes allowed as posts, OK to post as comments.
Only approved bots from the list below, to ask if your bot can be added please contact us.
Check for duplicates before posting, duplicates may be removed

Approved Bots

founded 1 year ago

MODERATORS

[email protected]

Community contributions to Element Web (Matrix client) are often not welcomed (github.com)

submitted 1 year ago* (last edited 1 year ago) by [email protected] to c/[email protected]

20 comments fedilink hide all child comments

It seems that community contributions to Element Web (Matrix client) are often effectively rejected. For example, see:

There are also many other PRs for Element Web/Desktop which have not gotten a review in a timely manner (see here). The request to improve the ~~terrible~~ notification sound has been there since 2017, and though several PRs have been submitted to improve it, they have been either ignored or rejected for an unknown reason (there should be an epic project going on which should make the six-year-wait legitimate).

When it comes to development of Element, there is a lot of unspoken, unwritten, internally shared rules among the internal team members. Your PR will be effectively rejected even if it works, unless it aligns with their goals, which you cannot know before submitting a PR.

It should be well noted that there is a clear and strict division between the internal paid workers and external volunteer developers who essentially provide the team free labor. The exclusive attitude of the team behind Element has discouraged the latter from contributing to the project. I myself have been one of the active localization volunteers, but I stopped contributing after I realized it has been free labor.

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 2 points 1 year ago* (last edited 1 year ago) (1 children)

Your case is pretty common with any project IME and it's not "cliquey" behavior. People really dont want to waste their time on something that's not ready to merge, and if the branch is pretty out of date it's probably not ready. I really doubt they'd complain about it being off by a commit or two, unless a merge conflict has come up since maybe.

[–] [email protected] 1 points 1 year ago (1 children)

Nah, we're talking a timescale of minutes here, a few hours at best. New feature, no conflicts, ready to merge. Fetch, rebase, push. Out of date almost immediately. Fetch new commit, rebase, push. Minutes later, out of date again.

See what I learned is, you can't outpace the sole project owner and principal developer, no matter how many other contributors the project has. Especially if he gets paid to work on the project full time. How do you compete with someone who has direct push access, commits every half hour, doesn't check PR's, and mandates rebases for fast-forward-only merges?

So my takeaway was, you don't. They're just not that into the feature, why should I be? Leave the branch exactly the way it is until someone asks for it to be made ready. They get 3 chances. If they don't merge it after asking for it 3 times, I tell them to checkout the branch themselves and take over. If I get code review feedback 3 times, I ask for peer programming. If they can't schedule it or don't want to, tell em check out the branch themselves and take over.

If they've got better things to do with their time, then you bet your sweet bippy I got better things to do with mine.