Andy Parkins [ARCHIVE] on Nostr: 📅 Original date posted:2011-08-10 🗒️ Summary of this message: A developer ...
📅 Original date posted:2011-08-10
🗒️ Summary of this message: A developer expresses frustration with the negative attitude towards new feature suggestions in an open-source project, suggesting a mentoring approach instead.
📝 Original message:On Wednesday 10 August 2011 19:41:51 Gavin Andresen wrote:
> > To be honest I feel a bit like every change that I (and I've also heard
> > this from others) propose is shot down, no matter how well
> > formulated. This is actively discouraging developers from joining
> > this project.
>
> Well, to be honest I don't think more developers adding new features
> are needed right now-- I think the project's critical needs are more
> people testing and helping to fix bugs and scalability issues.
(Rant follows; stop reading now)
That paragraph reveals a gross misunderstanding of how open source works.
People get itches and they want to scratch them. They aren't paid, so they
don't necessarilly want to turn up and be told which part they _should_ be
working on. The choice is not "bug fix that Gavin wants" or "new feature
that New Developer wants", it is "New Feature" or nothing.
Of course, nothing forces existing developers to accept these new features;
but the incredibly negative attitude on display when any new feature is
suggested is not the way to grow a community. The correct way is a
mentoring attitude -- offering opinions on how a new developer can get their
idea in rather than telling them why it will never happen.
> I don't see how dividing efforts between a 'bug fix' and 'development'
> branch will help fix the project's critical needs. If we did, I think
Again: that's not your call. People will work on what interests them. I've
suggested a couple of features both here and on the forum and been shot down
in varying degrees every time. Fine, but don't expect that I'm thinking
"well I'll become an unpaid bug fixing grunt instead".
I don't expect to be appointed head developer because I suggest an idea. I
don't even expect anyone else to implement my idea for me. But why should I
spend time on my own idea when the feedback is "no", "no", "we've already
thought of that", "not needed", "go away", "why not fix some bugs instead"?
I'm amazed that John Smith is as polite and persistent as he is looking at
the amount of effort he's put in putting a pretty face on the train crash
that existed before hand and seems to get no benefit of the doubt for his
work.
> there would be less pressure to help with the boring bug-fixing and
> testing of the bug-fix branch, which I think would be bad.
That pressure might be relieved if the community were able to grow a bit,
and people felt they had a personal investment. That means loosening the
reigns a bit; and perhaps a development branch would be the way to do that
while not compromising code quality.
I suggest a look at the way git itself is developed; it has the following
branches:
- master: the latest release + newly accepted features
- maint: the latest release + bug fixes only
- next: new features planned for inclusion, actively being worked on.
Often created by merging "topic" branches from individual developers
working on their current itch
- pu: crazy stuff; not planned for inclusion, but acting as a staging
area for people to show what they're working on
Andy
--
Dr Andy Parkins
andyparkins at gmail.com
🗒️ Summary of this message: A developer expresses frustration with the negative attitude towards new feature suggestions in an open-source project, suggesting a mentoring approach instead.
📝 Original message:On Wednesday 10 August 2011 19:41:51 Gavin Andresen wrote:
> > To be honest I feel a bit like every change that I (and I've also heard
> > this from others) propose is shot down, no matter how well
> > formulated. This is actively discouraging developers from joining
> > this project.
>
> Well, to be honest I don't think more developers adding new features
> are needed right now-- I think the project's critical needs are more
> people testing and helping to fix bugs and scalability issues.
(Rant follows; stop reading now)
That paragraph reveals a gross misunderstanding of how open source works.
People get itches and they want to scratch them. They aren't paid, so they
don't necessarilly want to turn up and be told which part they _should_ be
working on. The choice is not "bug fix that Gavin wants" or "new feature
that New Developer wants", it is "New Feature" or nothing.
Of course, nothing forces existing developers to accept these new features;
but the incredibly negative attitude on display when any new feature is
suggested is not the way to grow a community. The correct way is a
mentoring attitude -- offering opinions on how a new developer can get their
idea in rather than telling them why it will never happen.
> I don't see how dividing efforts between a 'bug fix' and 'development'
> branch will help fix the project's critical needs. If we did, I think
Again: that's not your call. People will work on what interests them. I've
suggested a couple of features both here and on the forum and been shot down
in varying degrees every time. Fine, but don't expect that I'm thinking
"well I'll become an unpaid bug fixing grunt instead".
I don't expect to be appointed head developer because I suggest an idea. I
don't even expect anyone else to implement my idea for me. But why should I
spend time on my own idea when the feedback is "no", "no", "we've already
thought of that", "not needed", "go away", "why not fix some bugs instead"?
I'm amazed that John Smith is as polite and persistent as he is looking at
the amount of effort he's put in putting a pretty face on the train crash
that existed before hand and seems to get no benefit of the doubt for his
work.
> there would be less pressure to help with the boring bug-fixing and
> testing of the bug-fix branch, which I think would be bad.
That pressure might be relieved if the community were able to grow a bit,
and people felt they had a personal investment. That means loosening the
reigns a bit; and perhaps a development branch would be the way to do that
while not compromising code quality.
I suggest a look at the way git itself is developed; it has the following
branches:
- master: the latest release + newly accepted features
- maint: the latest release + bug fixes only
- next: new features planned for inclusion, actively being worked on.
Often created by merging "topic" branches from individual developers
working on their current itch
- pu: crazy stuff; not planned for inclusion, but acting as a staging
area for people to show what they're working on
Andy
--
Dr Andy Parkins
andyparkins at gmail.com