How Can I Contribute
If you want to contribute to TWiki, you have come to the right place!
TWiki is an Open Source project, and as such relies on the support of users and fans to keep going. So anything you can do to help, is almost certain to be welcome!
There are many ways you can contribute, from simply telling the community your story, through helping support other people, or even becoming a fully-fledged down-and-dirty developer. Here are just a few of the more obvious ways you can contribute.
| Be an advocate. Tell your friends, tell your colleagues, present papers, use the tool, wear the T-shirt!
|| Tell the community your success story. Write a page starting with the words "TWikiSuccessStory". There are lots of examples already there!
If your story isn't a success - and we all know there are some - it's still equally valuable.
| Help out with documentation. If you find problems with the documentation, or find it difficult to use, or simply can't find the answer you were looking for, then don't just complain. Go fix it as well! You can contribute documentation updates just by creating a topic in this web with your proposed change or, better, by raising an item in the Bugs web.
|| Crush bugs. Bugs get reported in the Bugs web. If you are adventurous, you might try your hand at finding a fix, and post that alongside the report! The more relevant information you provide with the report, the more chance there is of there being a fix. Don't forget that your bug may have been reported already, and there might even be a patch to fix it. If you know how to fix a problem, you are very welcome to attach a unified diff to your report (but please make sure it's clear what version of the code it's based on!)
| Be a support god. The Support web is full of questions that need to be answered. If you are confident enough, feel free to answer any that you can! The support web is an entirely volunteer effort, so the more people who visit and help out, the better. It's a really good way to keep your finger on the pulse of TWiki activity in the real world. TWikiIRC is also a great place to help people, discover features that you never knew existed, and to meet and influence others. A lot of new users find their way to IRC, and there's a lot of friendly and knowledgeable people who hang out there too.
|| Contribute brainpower. The Codev web is a fertile ground for the seeds of ideas. It's made fertile by the many eyes who read changes to topics, and contribute to the development and refinement of ideas into reality. This isn't onerous; it just means staying aware of what's being discussed and when you think you can contribute, being prepared to speak up. Contributing doesn't just mean voicing opinions, of course. The goal is to refine ideas down to practical solutions, and that requires a positive outlook, and a preparedness to get your hands dirty, even if it's only to refactor (organise) a topic.
And don't forget; the newest contributor often has the freshest ideas!
| Write/maintain extensions. The most common way to get started coding TWiki is to contribute to the Plugins repository. Extensions are extra modules that can be plugged in to TWiki to support - for example - application integrations, new functions, and TWikiApplications. You can also contribute skins, which are tailored look-and-feel modules. Some extensions are contributed to the repository, but their original authors don't have the time to maintain them properly, so maintainers are always welcome too.
See SoYouWantToBeATWikiDeveloper for help in getting set up. Core developers and extension developers can RequestAccessToSubversion to maintain code directly in Subversion.
|| Develop new features. You don't necessarily need Perl skills to develop TWiki features. Many features have been contributed by people working in other areas, such as translations and TWikiApplications. See TWikiFeatureProposals for the community wishlist, and see where you can help!
| Join a Task Team. Task teams are groups of people who undertake larger chunks of work within the TWiki project. Task teams are largely independent, self-governing, mini-projects set up by like-minded people to get things done. Examples of task teams can be found at TaskTeamExamples. Anyone can form a task-team.
(STOPINCLUDE here, above statement gets included by ReadmeFirst
. Anything below is for discussion)
Crawford, thank you for taking the initiative, this is great stuff!
Suggestion: Merge this into the ReadmeFirst, which is the place new developers are looking first. Then remove this topic (and move this discussion into ReadmeFirstFeedback)
I would prefer one topic for where a new developer can ask for check-in rights instead of many "YourWikiNameWouldLikeToCheckIn" topics.
The CoreTeam has a slightly different view on the CoreTeamRoles, it is broader then what you described above. As such, there are more roles then just managing the MAIN branch, e.g. above text is something the TWikiEvangelistRole cares about. The current roles need to be reviewed and adjusted to the new development model. E.g. we have new MainBranchFacilitatorRole and DevelopBranchFacilitatorRole.
As such, Crawford would be a good fit to officially support PeterThoeny in the TWikiEvangelistRole and SvenDowideit in the DevelopBranchFacilitatorRole.
-- PeterThoeny - 24 Oct 2004
I intended this topic to support the changed development model we have been discussing in PostCairoDevelopmentModel, and as such I didn't think it was appropriate to attempt to rewrite ReadmeFirst.
The reason I thought having an application topic was better than a table in a single topic was that it does two things. First, it brings that individual to the attention of the community through the WebChanges and WebNotify, and second, it provides a platform for rather more detail about the individual than could be packed into a table. Though it was a marginal choice.
As you know, I believe that assigning roles to individuals has negative knock-on effects on the community, pushing away people who would otherwise contribute and bringing excess pressure to bear on those identified with the roles (among other negatives!).
Personally I don't want to be constrained by a "role". Where I can be an evangelist, I will be. Where I can contribute architecture ideas, or code, or documentation, or help out in Support, or in plugins, I will. I will help wherever I can see something that needs doing. People who are very active in specific areas might become identified with a role, but assigning them up-front I think is a big mistake.
-- CrawfordCurrie - 25 Oct 2004
HowCanIContribute and ReadmeFirst are related. We do have too many entry points of what a new person should read, therefore it pays off to put some thought into consolidating content and links. This applies to the Codev web and also to the TWiki web.
On roles, I understand your point but I disagree respectfully. Also in a volunteer environment it is important to have a sense of ownership in order to be motivated. For example, RichardDonkin is the expert on I18N. Even though he "owns" this domain, other people still can (and do) contribute in this field. Maybe it is better to mentally replace "owner" with "coach"
-- PeterThoeny - 28 Oct 2004
Peter, as you know my involvement with core code changes came about because as a plugin developer, I was screaming frustrated with the core team. What seemed to me - and others - to be simple changes to provide basic support to plugins were taking in some cases years to get done, and in some cases are still not done.
I'm a volunteer, and in response to your assertion that "ongoing ownership is important" I can only observe that this is patently not the case. If there was any sense of ownership within the core team roles, I could have expected a positive response to questions addressed directly to the role owner. The reality is that for busy people, ownership of a long-term role in TWiki is a burden, not a benefit. As a means of delegation it has clearly failed, as most of the roles were never fulfilled by the assigned individuals.
Assignment of roles creates toes that people are afraid of treading on. Roles in TWiki also discourage contributors for another reason; people think "why should I do this, when someone else, who contributed absolutely nothing, nada, zip, is going to share, or even get all, the credit?". This is basic psychology. Look at the twiki sourceforge project. How many of the listed developers are actively developing TWiki?
The fact is that role assignment has been instrumental in stopping me contributing to the core code in the past, and I know for a fact that it has stopped others. The last year has only served to reinforce how dysfunctional the whole core team concept is. You yourself have asserted several times how under pressure you are, even in the context of a 9-member core team. What makes you think this situation will be any different a year from now? You are in the process of once again reinforcing the status quo. Rather than empowering potential contributors, you are just driving them away.
Perhaps you prefer it this way; I am never sure. You have pointed out that the competition (JotSpot etc) owe a lot to TWiki for many of their ideas. They have even implemented many ideas that never made it into TWiki. It is pointless to complain; they never made it into TWiki because the development model made it impossible for them to get in. That's the price paid for low-velocity development.
TWiki development isn't like being on a train. It's like being on the slow boat to China.
-- CrawfordCurrie - 28 Oct 2004
Whilst I think there is value in listing what the roles should do, I am with Crawford on assigning them. How about we rename them *Role -> *Tasks, with the understanding that anyone can do a task, and the task being instructional about what is important.
The concept of Core Team does not work here. Peter gets the sharp end of it, being pressured from every angle. I am grateful for his effort, but again, its the wrong model for me. With 140 odd plugins there is a lot of strategy needed doing. Proof is in the PatchProposal figures which are sky high, our PeterPleaseComment requests ignored.
- And we are working on improving the speed, the DEVELOP branch you initiated helps a lot! Crawford, statements like these are not productive. Instead of fueling a "we active developers and they unresponsive core team", I prefer us to work on a "us developer" style that includes the core team, which is more healthy for the TWiki project. -- PeterThoeny - 31 Oct 2004
I am glad for the DEVELOP branch. It is the first really good news in years on this project.
-- MartinCleaver - 28 Oct 2004
The DEVELOP branch is a move into the right direction. However, it does not yet ease the workload on the small core team. It will be reduced once we have the HelpWanted CoreTeamRoles filled. And, may be I should get paid to spend more time on TWiki.org...
HowCanIContribute and ReadmeFirst are related. We do have too many entry points of what a new person should read, therefore it pays off to put some thought into consolidating content and links.
-- PeterThoeny - 30 Oct 2004
Another issue is that is not that visible from the Codev main page how a new developer can contribute. The stuff in the WebLeftBar is a step in the right direction, but is visual noise to the casual observers (ie, those who are reading the main content area). A topic that describes how one can contribute, where to look and which tools are available that is prominently published in WebHome would help a lot to guide new developers.
- They are not ignored, we just have a different view on responsivness. Agreed, I have too many hats on, HelpWanted points them out. And SamHasler did a positive move to help out by joining the CoreTeam. -- PeterThoeny - 30 Oct 2004
-- RafaelAlvarez - 30 Oct 2004
First step done. This topic is now included by ReadmeFirst just before the information for contributors
-- RafaelAlvarez - 01 Nov 2004
how can I Copy a Table Row To Another Table?
Thanks for Help
-- Abiga Himgus - 2013-03-15
Abiga: Please ask support questions in the Support web.
-- Peter Thoeny - 2013-03-15
- Exactly the reason why I said we should collaps this topic and ReadmeFirst. That is, one single entry point for new developers, with links to secondary "how can I contribute" pages. -- PeterThoeny - 31 Oct 2004