gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: side projects and sub projects


From: Ivan Vučica
Subject: Re: side projects and sub projects
Date: Sun, 28 Feb 2016 14:27:38 +0000

I've thrown away three drafts of a response already, because anything I could add will amount to bikeshedding.

But I'd still like to voice my thought that all the points being raised are important. Thanks for this thread (including civility on display in it).

On Sun, Feb 28, 2016 at 2:21 PM, Richard Frith-Macdonald <address@hidden> wrote:

> On 27 Feb 2016, at 15:55, Patryk Laurent <address@hidden> wrote:
<snip>
> Hmm... this list does capture a lot.  Suppose to get started there was a survey targeted at (potential) Users in which people ranked (1) the above list in terms of which are most important to them for GNUstep; and also ranked (2) what they perceive as the major impediments to using GNUstep in that way (e.g., bugs; user docs; website; app availability; missing tools; look and feel; up-to-date distribution; not enough activity on irc; etc.)
>
> At the very least, this could be interesting information... but it could help guide and plan.
>
> Maybe a third question of such a survey (for Users that are also Developers) could ask people to rank which of the impediments they felt they could see themselves likely/capable to work on within the next e.g., 12 months...

Yes, that all sounds very reasonable/good to me.

I think that last point is key since, if there's nobody to do something, it's not going to get done.

However, in the past some people have complained about being asked to do anything themselves, whether because of genuine misunderstanding or simply because they are users/abusers (trolls).
So  'work on' would need to be clearly defined to avoid prejudices about contribution==coding.

There are a lot of ways someone can volunteer (particularly when looking at a side/sub project as a whole, rather than a small issue within it);

administration and leadership (communicating and supporting other people in a team and even bringing in new people)
techical development (the obvious;  but we shouldn't let people get away with saying they can't contribute because they don't code)
formal testing (real commitment to rapid turnaround of real testing, not just occasionally trying out an app)
documentation/publicity (software developers are rarely good at this)
finance (if you can't contribute anything else, you might be able to pay someone else to do so)

Unfortunately, if people want something but can't actually cooperate to make it happen, there's not a lot of point offering to support it.
_______________________________________________
Gnustep-dev mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/gnustep-dev


reply via email to

[Prev in Thread] Current Thread [Next in Thread]