Tags:
archive_me1Add my vote for this tag stale_content1Add my vote for this tag create new tag
, view all tags
The discussion on nominating CoreTeam members started in CairoRelease, I moved below post by Martin over to here.

-- PeterThoeny - 31 Mar 2003

Given:

  1. The pressure of work under which the CoreTeam is currently suffering, and
  2. The several people (CodersForHire, ConsultantsForHire, and the more active Plugin authors who currently give away their time)

Why not restructure the core team so that it reflects today's contribution levels?

  1. Ask your most frequent and best coders whether they would like to join the core team (I'm guessing most are too modest to ask to join)
  2. Put in place and assign specific roles (e.g. TWikiPatchMaster, TWikiProjectManager) to ensure other people know how they can and are expected to help
  3. Acknowledge the fantastic contributions work done by some of the now-contributing-less-frequently CoreTeam members (e.g. MikeMannix, NicholasLee, AndreaSterbini) and then suspend them to a Dormant CoreTeam part of the list. Revised the CoreTeam list again when DakarRelease work commences.

TWiki Users: If you have submitted significant code contributions (i.e. patches that have been incorporated into the core and/or plugins with many active users) and feel that you could handle and would like a formal role at TWiki.org please add your name to this table. Likewise, if you think that someone else should be nominated, please add them (or second them) and we'll check their availability, willingness and acceptability.

Now on CoreTeam

Name Significant code contributions To head up Nominated/supported by Accepted/Declined
WalterMundt     MartinCleaver 18 Aug 2003 - now on CoreTeam
ColasNahaboo KoalaSkin to be decided MartinCleaver 18 Aug 2003 - now on CoreTeam

Other Nominations

Name Significant code contributions To head up Nominated/supported by Accepted/Declined
PeterNixon MegaTwiki Incorporating features into core MartinCleaver
MichaelSparks DataAndCodeSeparation Standardising ReadWriteOfflineWiki   Declined.
CrawfordCurrie ActionTrackerPlugin, TocPlugin, TWikiDrawPlugin, PowerEditPlugin, original GenHTMLAddon   MartinCleaver Would accept, but also has possible conflicts.
MattWilkie     MartinCleaver Declined - doesn't grok perl enough

Democracy rules. wink

-- MartinCleaver - 30 Mar 2003

Shortly before the BeijingRelease the CoreTeam already had some discussion about restructuring the Core Team, e.g. getting suitable folks on board and initiating an honorable CoreTeamHallOfFame for those tem members who cannot devote enough time to the project anymore. We did not follow up because of lack of time.

A nomination is a good start and can narrow down the selection. However, I think other factors are important and need to be considered as well, like quality of spec/code/doc contributions, willingness to devote time, and team player. Ultimately the persons nominated and the Core Team members should make the decision.

And yes, defining the roles will help (sense of ownership). Stay tuned.

-- PeterThoeny - 31 Mar 2003

To aid the objectivity/memory prompting of this process, I did a quick tally of number of message contribution to the Plugins web. The method is by no means perfect as people might have been just chatting (like me), and might exclude people (like Michael Sparks) who in my opinion have made great contributions but been relatively quiet.

I'll be back to edit more, I have to go now.

BTW: If I don't nominate you and you think I ought to have done then this means you think you should be nominated. No shame in that, nominate yourself!

Likewise, if I nominate someone they don't have to accept! So! Nominate, people!

Anyway:

Grand Total 3995
PeterThoeny Total 915
AndreaSterbini Total 357
ColasNahaboo Total 260
MartinCleaver Total 176

CrawfordCurrie Total 152
MattWilkie Total 148
DanBoitnott Total 93
RichardDonkin Total 90
JoachimNilsson Total 85
ThomasWeigert Total 78
AlexeyEfimov Total 77
MartinWatt Total 77
MikeMannix Total 75
DavidWeller Total 62
JohnTalintyre Total 60
WalterMundt Total 56
AnthonPang Total 55
PeterKlausner Total 55
PeterMasiar Total 54
GrantBow Total 53
SlavaKozlov Total 50
DennisDaniels Total 47
SvenDowideit Total 47
JohnRouillard Total 45
MartinRaabe Total 43
MikeBarton Total 43
TaitCyrus Total 35
DaleBrayden Total 34
-- MartinCleaver - 02 Apr 2003

Martin, while I appreciate your nomination of myself to the CoreTeam I don't feel I can accept. I don't grok perl and have a limited understanding of programming in general. I'm more likely to break things than fix them. On the other hand, I feel quite qualified to join the Gripes, Wishes & Noisemakers Team. wink

-- MattWilkie - 03 Apr 2003

Well, my opinion is that most Open Source Projects (lets call them OSP) come to some "growth crisis" at some point (basically when the software is "good enough" for the original author). TWiki seems to have reached this stage, so how should we go on?

My suggestion: try to design a process with more frequent releases, so that contributors can be motivated since they will have some hope that their contribution be incorporated in the foreseeable future. This will means that some releases will bring not a lot of new features, so it should be important that upgrading should be as painless as possible (just unzip & run an upgrade script).

Also, very often OSPs gain new life via "mods": contributor "distribute" their own flavor of the OSP, picking the version of the core + a set of "approved" patches and packaging them, not unlike the linux distributions. A recent example being the "emule mods", or the games on top of games engines such as Quake. Then the job of the Core team is to provide hooks for mods... For instance, the KoalaSkin was done because I could not push all the enhancements I wanted into the core. But I think it was unavoidable: many of my decisions were debatable, and I could not have rallied all of the community towards them. So the best way was to create a coherent spinoff to test things in real life. What I expect from TWiki is that it should be easy for me and others to continue providing these kinds of Addons, knowing that we could not agree in a reasonable time frame on a common look & feel...

Anyways, the job of the Core Team could be more limited: just designing and monitoring the process.

(On a personal note, I do not feel perlish enough to be part of the Core Team, but I can give a hand).

-- ColasNahaboo - 08 Apr 2003

Colas said it right: Twiki is good enough for some memebers of CoreTeam, and as a result many changes promoted by (majority?) of less-core users are rejected. Like NoRegisterDownload, SimplerDefaultTemplates, SimplerTWikiDistribution, and many more.

I appreciate all the hard work of memebers of CoreTeam, but resisting some changes hurts the Twiki community, IMHO.

Later: In case I was misunderstood, it was a (possibly ill) joke frown . I definitely do not want PeterThoeny or any other CoreTeam memeber to go. How to avoid forks and incompatible mods... Or, I am looking for a mod with CommentPlugin, FlexibleSkin, and couple of renaming. Willing to work on docs.

-- PeterMasiar - 09 Apr 2003

Colas: Having seen the depth of functionality you have provided with KoalaSkinPlugin, I am surprised that you consider yourself 'not perlish enough' to be part of the core team. Do you think you could handle the role of 'Standardising such features as SavemultiCgiScript into core, coordinate skin developers'?

Peter M: Helping with 'documentation' is a rather broad goal, and difficult to measure. Is there a more specific task in this that you can see yourself doing? For instance, keeping tally of what patches have been submitted to the core team but not applied? (It could be argued that that particular role is awkward to segregate from that of TWikiPatchMaster as otherwise a person is given 'all talk, no walk'. But you think of a role. In fact, how about coming up with an initial list of roles that we need to fill, either off the top of our head or from the set of roles used by another OS initiative.)

-- MartinCleaver - 12 Apr 2003

Re: In fact, how about coming up with an initial list of roles that we need to fill, either off the top of our head or from the set of roles used by another OS initiative.)

Sounds like a good idea, but I only have a few thoughts (really just one), and I captured one or two from above, the start of a list is below my signature line (everyone should feel free to add to it there or move it somewhere else on this page or another page). Ok, I lied, I started writing and just kept writing, but I am sure I went overboard and I need to be brought back to reality. And now I realize that some of this is more apropos ImproveTWikiRating, but I'll leave it all here for now.

-- RandyKramer - 12 Apr 2003

Potential TWiki Developer Roles

  • Chief Designer / Benevolent Dictator (re: features, direction of project, strategies and tactics) / Project Manager — the obvious nominee (and perhaps not an elected position, but a "position for life") (??): PeterThoeny. Could/should the control of features be separated from control of the project?
  • One or more advisory bodies that have the ear of the Chief Designer / Project Manager:
    • A Board of Directors?
    • A team of Core Developers?
    • A semi-official Users Group?
_Three advisory bodies may be overkill for a small project, maybe even one is, but I guess I'm looking to have some group of people that the Chief Designer / Project Manager is willing to consider advice from or perhaps even must answer to. On the other hand, this is PeterThoeny's project -- maybe the only appropriate thing to do is fork if one or some group of people see the need and cannot get change from within (I'm certainly not in that position but I would like to see certain improvements in TWiki).
  • "Standardising such features as SavemultiCgiScript into core, coordinate skin developers" -— like below, the Benevolent Dictator has the power of decision
  • TWikiPatchMaster (among other things, keeping tally of what patches have been submitted to the core team and which have been applied and which have not) (of course, the Benevolent Dictator makes the decision)


<back to me commenting vs. listing developer roles:>

So, I'm starting to see a pattern here (in my own thinking / writing) — I continue to give the project leader / chief designer / benevolent dictator the power of final decision (because, I guess, in my mind it is his project — he started it, etc., etc., etc.). If he sets direction and others are willing to help moving in the direction he sets, then there is room for others to participate. (Like, if he agrees that we should improve the Sourceforge rating, then someone could bring a strategy to him for doing so, then if he agrees to the strategy, then that someone could move forward and implement that strategy. If he doesn't set direction — not sure what I want to say here &mdash I'm trying to say something like, as the leader, for the good of the project he should take advantage of help that is offered — in order to do so, potential helpers must know the direction he wants to move the project in (or wait to be told step by step what they should or may do) — I think you get more out of others by setting a direction and giving them some autonomy to proceed on their own. (Am I giving the Project Leader more power than I should?)

Anyway, on a different tangent (starting from somewhere above) — another alternative is a fork. Why do I keep bringing that up if I don't see the need for it? -- I guess because that's the big other alternative I see -- this is Peter's project, "we" either:

  • do things his way
  • start a project to do things differently
  • or some compromises occur -- Peter may be willing to allow us to head off in certain directions within his project, against his preferred direction, as long as it doesn't do anything do detract from his preferred direction (including costing his time) (or, even though detracting from his direction he gains some benefit that makes it a fair tradeoff — like more developers who do some work on his preferred direction and some in other directions) — I think a leader can use such compromises to further his preferred direction. For example, preventing a fork keeps a larger pool of developers and whatever in his project, so that they can both achieve their goals (which might not fit the leader's preferred direction) as well as help move in the leader's preferred direction.

One more thought: could there be a fork that is only a "publicity fork"? What I'm thinking is that, if Peter doesn't want to improve the publicity for TWiki within the TWiki project, there is nothing in the GPL (IIUC) to prevent some group forking from the TWiki project without any intent to improve the code (because there may be no developers among the forking group) but only to create a new project on Sourceforge that makes TWiki available for download and tries to create a high Sourceforge rating.

The one limitation I see is that, (IIRC) TWiki is Peter's trademark -- if such a fork was created, it would have to use a different name. Just thinking out loud:

  • The project could (possibly?) have a name like NotTWiki, NotATWiki, (or either of those with the spelling "Twiki", or an "acronym" name, like NAT (for Not A TWiki, but a bad choice because of confusion with Network Address Translation).
  • But, even though the fork used some name other than TWiki, it could (I think) describe it's mission as something like "to distribute Peter Thoeny's TWiki &tm; and publicize it" (and draw additional developer's to either Peter's project, or the fork).

Anyway, I don't know why I wrote so much — I am not advocating a fork in any way shape or form. I'm trying to remember what if anything we've heard from Peter on the subject of improving the visibility of TWiki. Maybe, as the defacto Project Leader, he needs to weigh in and say either he'd like to see additional publicity, please proceed, or please proceed but I (he) won't allow downloads without registration, or whatever, and then you make your choice. (What I didn't quite say above is that there could be a project, AFAICT (IANAL), that simply makes Peter Thoeny's TWiki available for download without registration. Maybe the "Twiki Publicity Project" (to avoid using TWiki in the name of the project, on the assumption that it is Peter Thoeny's trademark.)

-- RandyKramer - 12 Apr 2003

Want nice acronym? What about NICE: Nice and Intuitive Collaboration Environment. With mission: "make the best perl wiki (Twiki) easy to install, and intuitive to use."

-- PeterMasiar - 12 Apr 2003

Just fixing some typos, grammos, formattos in my comments of yesterday.

-- RandyKramer - 13 Apr 2003

I get the feeling that there is a significant mis-understanding. I have not found Peter rejecting a given direction. Please don't read much into the debate about registration - especially given that TWiki is GPLed. If a developer proves themselves in their ability to take on TWiki development, then Peter and the other core developers are keen to take them on as a new core developer. Rather than hindering what the other core developer do, Peter actively helps to keep code quality high and almost invariably his advice is spot on. In Peter we have an ideal head of an OpenSource project: he actively looks for agreement on changes and works very hard to maintain overall quality.

-- JohnTalintyre - 13 Apr 2003

John, Richard, PeterT, who would you like to see join the CoreTeam? Not saying that you are rejecting a direction, but direction do you support? Or shall we stay still? Randy is right - leadership is about instigating change, I see only the status quo. Andreas, Nicholas, are you still reading? Mike - what about you, you've said nothing in months - have you given up?

    Response removed. Membership of core team isn't necessary for me to continue on the stuff I'm working on. The added hassles I would get from being part of the core team are not worth it. (I'd get people whinging about not writing docs, not rewriting the entire codebase and so on. Life is short.) -- MichaelSparks - 23 Jul 2003

-- MartinCleaver - 17 May 2003

Re: "Randy is right - leadership is about instigating change, I see only the status quo." — While it's nice to be called right, I don't think that's what I said (I shouldn't ramble so much), nor what I meant to say. Sometimes leadership is about maintaining the status quo. For example, avoiding changes in direction on a project as it nears a deadline. In particular, I wish some of the open source projects paid more attention to getting the functionality complete rather than adding eye candy. (No, I'm not referring to TWiki, but not sure I want to mention project names in any case.)

-- RandyKramer - 18 May 2003

I'm keen for good developers, who want to contribute to this OpenSource development to join the core team. Just being a good programmer is not enough, nor is just wanting to contribute; it takes both. Martin was probably looking for names, I'll base my thoughts on who has contributed good code (either as a plugin or fork) and want to incorporate work into the core.

-- JohnTalintyre - 18 May 2003

Changed my comments above.

-- MichaelSparks - 23 Jul 2003

I would accept along the lines of MichaelSparks, but these days I don't have as much time as others to dedicate to the project (I should update my user topic!), due to both work and family matters. MegaTWiki is stable for now, and in current use by many Sun Microsystems internal sites. I have thought of some ways to get MegaTWiki's changes to the core code into memory via plugin or config file; My current plan is to make those changes, get it working with a recent TWiki release, and post/maintain it from there.

-- PeterNixon - 04 Jun 2003

I became a plugin author for two reasons; first, I desperately needed certain functionality for work, and second, I needed to be in control of my own time allocation (in the life+work+twiki balance I'm afraid twiki comes last). While I think I probably could contribute, I'm very cautious of making a committment I couldn't fulfil. I'm really not interested in forking twiki, I just want to clean up what's already there so the next leap forward is really that - a leap, not a hop. So if the intent is to refactor, and the chunks are manageable, I guess I could contribute.

-- CrawfordCurrie - 05 Jun 2003

Maybe we need to find some students with lots of spare time who are also great coders and good at making considered design decisions smile ... Seems like many TWiki people are busy with their day jobs or real lives, making it tough to contribute much time to the project. I'm just guessing here, but that's how it seems based on very little evidence!

-- RichardDonkin - 05 Jun 2003

It will not be easy; here are couple of red flags against getting involved:

  • One look at sourceforge rating will suggest that Twiki is dead project.
  • In NoRegisterDownload we argued against requiring registration. Students are more radical and might not be interested to spent time if project looks like not 100% GPL.
  • Many students will not touch non-OO code with yard-long stick. And will prefer Java, not perl.
  • Students have short time-frame. Many coders smarter than me agreed that learning curve to become Twiki-competent is very steep.
  • If website is not graphically nice, they will just go next door. My own son, succesfull (and good) web designer, flatly rejected even to look into Twiki proprietary templating system - he values his time too much.

-- PeterMasiar - 06 Jun 2003

Time to revisit this. I hereby renominate Crawford and Matt Wilkie, and ask Matt to consider that it really is less important that he grok Perl than important that they at least say/do something here at TWiki.org. Not wishing to be rude, but stats do show that very few of the core team do most of the work.

-- MartinCleaver - 13 May 2004

Edit | Attach | Watch | Print version | History: r31 < r30 < r29 < r28 < r27 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r31 - 2004-08-03 - MartinCleaver
 
  • 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.