Tags:
twiki_community2Add my vote for this tag create new tag
, view all tags

Codev Community

The developers community having an interest in a rapid, high quality evolvement of the TWiki collaboration platform. The developers fulfill ContributorRoles.

The CoreTeam, after polling the developers and users, will set directions for future TWiki development in the spirit of the TWikiMission.

  TWiki Community - TWikiCommunityGroup
  Codev Community

See also: ReadmeFirst, TWikiCommunity, PluginsCommunity, TWikiMission, AppealToCodevCommunityByCoreTeam

-- PeterThoeny - 05 Aug 2003

Discussions

I would have much warmer and fuzzier feelings about the notion of a Twiki "community" if the above read "The CoreTeam, after polling the developers and users, will set directions for future TWiki development in the spirit of the TWiki Mission". It seems to me that open software projects are like raising kids: after a while, the kid starts wanting to be what he wants to be, not what the parent wants him to be. If the parent tries to control the kid beyond a certain point, the kid becomes alienated from the parent and (moving back to the open software idea) the kid forks off on his own.

Every project needs leadership, but I thought the most fundamental concept of open source projects is that a diverse community of people can develop better software faster than when a select group of developers do all the directing and developing.

This post is only peripherally related to Mr. Spark's issues, although they did prompt me to expressing my opinions about how codev seems to me to have operated in the past.

-- DavidLeBlanc - 11 Aug 2003

Given Peter's enormous commitment to the TWiki.org, I would personally do much more than give him the benefit of the doubt smile

Many have given generously to TWiki, but without Peter's long-standing commitment TWiki would be another promising OpenSource project that has stalled. I have seen so much encouragemet from Peter to others (including me) that it is very hard to equate that with the negative debate that frequently sprouts up in Codev. Yes, let's hear many voices and yes they will not all agree, but please let's all take a positive attitude to where TWiki.org is going. More than anything else we need more hard working coders, other contributions are great, but an OpenSource project lives or dies by code contibutions. The Plugins Web has had many great contributions, we need to work out how to harness that energy for the TWiki core.

Unfortunately I have litte time to contribute to TWiki these days. I made some fairly significant code contributions in the past and I'll do my best to keep supporting them. I hope others can step in as major CoreTeam players, you'll find it hard work (probably more than you imagine) to keep up the high standard of TWiki code; but I certainly found it very rewarding and hopefully like me you'll have excellent feedback from the TWiki community and Peter in particuar. I haven't found time to update our work TWiki from the Sept 2001 release - but, that is still very powerful and never goes wrong.

-- JohnTalintyre - 11 Aug 2003

David, this is good feedback, I changed the wording accordingly. It is in line with how the CoreTeam thinks and acts (time constrains put aside)

-- PeterThoeny - 12 Aug 2003

Thanks, now experiencing warmth and fuzziness wink

If I may be so bold as to suggest how to realize this: TWiki could/should have a means of voting on various features in order to help the CoreTeam prioitize items for development. I'm not sure what that would look like, but perhaps it might look like a page of proposed new features with an option to prioritize them, vote yea/nay or have a write in option on a per poster basis. Just a thought...

-- DavidLeBlanc - 12 Aug 2003

Voting could be used indicate suitableness for inclusion in TWiki and popularity of the proposed feature. Actually saying what should go in a release is a problem - so much depends on a developer putting time into fully developing, test and documenting the feature. We do need more developers. How about this.

  • Features voted for
  • If no one on CoreTeam will take forward then
  • Someone in Codev can put forward their name
  • CoreTeam assist
  • If successful, developer would be invited to join the CoreTeam

-- JohnTalintyre - 12 Aug 2003

Yes, a core team more oriented towards empowering developers than towards trying to satisfy a user community (by doing the development themselves) might reenergize TWiki development. I personally, in the past, have had the feeling that the core team, and particularly one member (long gone now it seems) who I felt ran rough shod over my attempts at contributing and seemed interested more in recasting my ideas as his, was more exclusive than inclusive. The result was that I lost a lot of my interest in, and enthusiasm for, participating in TWiki.

I have had the feeling in the past, that features are suggested and past that, there has not been much in the way of including the community in deciding which features are to be worked towards the next release. It seemed (seems) like there's a chasm between the developer team and the larger community that excluded the community rather than included them in creating TWiki's development roadmap. (Please, none of this should be seen as condemnation or criticism of the efforts and successes of the CoreTeam to date: it just seems to me that it's not working as well as it could and does in other open source projects. I'm more interested in suggesting where roadblocks might exist and offering suggestions for making the process work better.)

One way to encourage developers (and potentially cut down on the signal to noise ratio, if it exists) is to add a checkbox or some such to the feature suggestions page that indicates whether or not the submitter is interested in developing the code to implement the suggested feature. The complimentery action on the part of the CoreTeam is to evaluate and either encourage or discourage the developer in a timely fashion and then, if s/he is going to be encourage to do the development, to commit to encorporating the new feature into a specific upcoming release as appropriate (it could be core or plugin or...). This would have the effect of encouraging the developer and offers him/her the knowledge that her/his work will actually see the light of day. Since there's little fortune to be had from open source development, there should be some fame eh? wink

It strikes me too that if people are encouraged to review and vote for new features, this would help decide which should have priority. I wonder if it's possible to have a template for new features that has a priority box and a button for "add my vote: yes" or "add my vote: no" that would bypass the edit/preview cycle to make it less time consuming. It should not preclude the ability for the community to add comments though. A box at the top of the New Feature Requests page could automagically keep track of the most voted for/against/most commented features too.

Just my $.02

-- DavidLeBlanc - 13 Aug 2003

Edit | Attach | Watch | Print version | History: r16 < r15 < r14 < r13 < r12 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r16 - 2007-01-29 - PeterThoeny
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.