Avoiding Feature Bloat

[josephwegner]

This is a crosspost from Pullup.. Pullup doesn't currently style long text blocks very well, so wasn't a very good place to post..

---

One of the major difficulties that I foresee occurring with pullup.io is feature bloat. By design, there is going to be a ton of contributions/PRs for pullup.io. And, somewhat unfortunately, new features are more fun (and more impressive) to build than bug fixes.

The decentralized nature of pullup.io development rewards feature bloat. We need to be intentional about avoiding it. I don't quite know how to do this, but I think it's important to decide early on. Currently pullup.io is clean, minimalistic, and easy - let's keep it that way.

Some options:

• Feature addition pull requests needs to get three 👍 from pullup member before they are merged
• Feature pull requests - if tested and meet style requirements - should always grant the contributor pullup membership, even if we decide the feature should not be merged
• We should suggest heavily that contributors work through the issues list, rather than coming up with their own work. If they want to add features, create and issue and discuss it with the pullup community first.

[chall8908]

The only thing I'm shaky on is the second point. I'm not necessarily against it, I just feel the requirements might be a little lax for a long term solution. Perhaps it could be part of the deliberation process?

I'm thinking PR's would work something like this:

1. Validation - During this phase, the community determines if the feature fits the goals of the site. This is the only step that can take place before the PR is made and any discussion should be referenced in the PR.
2. Testing - This phase ensures the feature(s) work and, if applicable, look nice.
3. Voting - Every pullup member is allowed to vote on if they want the feature implemented. Pullup members that dissent to the feature can still cast a vote in favor of giving the implementer membership. If the PR gets a net positive number of votes after some predetermined minimum (e.g. 3), the PR is merged and the implementer gains membership. If the vote fails, getting a majority voting in favor of granting membership will still grant membership.

Seems kinda complicated, but that's mostly just because we're not very large yet and I'm unsure how many people will actually vote.

[josephwegner]

I like that plan, my only worry is that there is too much friction. There's little value for a PU user to pull, test, and vote on a new feature. Voting really only makes sense if you've got a large number of users willing to vote.

I don't want to create a situation where an applicant puts a bunch of time into developing a feature, and then gets stuck in limbo because we decide that their feature isn't super useful.

[chall8908]

This solution definitely isn't without it's problems but, given that we, as a community, aren't the final arbitrators for who gets in, I don't think we'll have too many issues. So long as @megamattron or @pents90 step in when the community guidelines fail, we should be fine.

Really, I imagine that we'd end up with a fairly small group of users that do most of the vetting of features and a larger set of active voters. I imagine a majority of pullup users won't really take part in development past getting in initially.

[megamattron]

I'm very worried about friction here as well. I was thinking about writing something about future direction, but I don't quite have all my thinking together about it yet. In general though, I'm not as concerned about feature bloat as I am about burdensome processes and bureaucracy. So far I've made a conscious decision to merge something when at all possible. Nothing seems to kill enthusiasm more than too much discussion about a change, or the details of the change. So I try at least to keep things moving forward and we can adjust as we go.

Basically, the site developed much faster than I thought it would. I thought it would take a while to get to HN feature parity, but we chewed through that task list in a few days. The ultimate determination of where we go next is determined by the code everyone writes, but I also find myself trying to follow a few guidelines:

1. Keep it fun.
2. Try to say yes. Try to merge if at all possible, try to get on board with someone's idea. It might not quite work out initially, but you might end up somewhere more interesting. Also, it's more fun (point 1).
3. Be fine with breaking it. You can always fix it, and it allows for point 2 and point 1.

Other than that, I have no idea! This can be a great and dubious experiment. Maybe this will end up being a SEO optimized blogging microselfie social network, for nerds. Who knows! There's something fun about it being a bit out of control, and I think that's important to preserve.

[chall8908]

@megamattron if that's the direction you want to go in, I can get behind it. Sounds pretty exciting!

[mreinhardt]

Nothing seems to kill enthusiasm more than too much discussion about a change, or the details of the change. So I try at least to keep things moving forward and we can adjust as we go.

There's something fun about it being a bit out of control, and I think that's important to preserve.

These statements and your three loose guidelines make me happy. We all have our day jobs that bombard us with requirements, bureaucracy and constraints. I don't think I'd enjoy using my precious and dwindling free time contributing to this project as much if I found the same here.

A bit of guidance is a good thing, but I think trying to exercise too much control over this project would strangle the uniqueness from it. There is a freedom that seems inherent in its design and purpose, so why try to cage it. Let's try letting go.

[rickhanlonii]

How about creating a dash where users can turn on features other users have written, not unlike Google Labs? This allows you to pull into the main feature set the PRs that best align with the goals of the project, but still allow for experimental features created by users trying to get their PRs or trying out new ideas.

Seems to me like it's the best of both worlds--lots of possible features and improvement, without feature creep into the core.

[josephwegner]

@rickhanlonii That's a pretty fun idea.. It would take some serious infrastructure work, but I do like the idea of labs. The main difficulty is it would limit us to new features that don't change the data model. That might be a fine limitation, as features large enough to change the data model probably need to have a lot of discussion and invested testing time, anyways.

If we do do this, we should have the active "lab" features prominently displayed somewhere, with a link out to the Github PR. That way it's easy for users to provide feedback or report bugs on things they are testing.

[josephwegner]

I'm closing this, because @megamattron's answer suffices and is very correct.