Date: 2012-08-15 12:23 pm (UTC)From: [personal profile] eylul
eylul: (0)
First of all it is awesome to hear there was an effort to make this happen, even through the attempt failed. (I wish it hadn't been rejected altogether, we wouldn't have lost the time in between) I am looking forward to seeing your post.

I'm not certain about splitting coders into two committees, but your arguments in that direction are compelling. This might come in part because I'm from a sort of crossover background, in that I've done both back and front, so for someone like me I would love a centralized place for all coders. I also find it easier to pass work back and forth, especially on asynchronous web apps. Do you think some kind of two-tier structure would work? A coding committee with front and back subcommittees? Or maybe a coding committee that manages feature development across both teams and maintaining consistent development standards, presiding over front and back end committees that are more focused on volunteer management, community-building, knowledge-sharing, etc. within the expertise groups?

I am very glad you brought this up. Dividing front-end and back-end coding (or browser side and server side programming) was a late addition to this document, and something I debated on for a while before deciding on.

I want to clarify one thing first, even through I know this wasn't what you meant exactly. I am not defending that each volunteer should only be limited to a single skill. What you describe isn't just true for front and back-end coders. It is also true with Design and Front-end as well, or to a slightly lesser part Systems and Backend. none of these skills are 100% distinct, but merging them together into subcommittees is what got us into trouble. I think the correct solution is simply for people to be in multiple volunteer pools if they want to, and to solve our need for communicate between committees by encouraging volunteers to spend more time in cross committee chat room.

This will simplify keeping track of different level of expertise of a volunteer in different skill set, (a person might need mentoring on front-end side, but might know enough to be a mentor on other) and give the volunteers themselves the opportunity to shift their work from one side to another with less pressure from emergencies and such.

About passing work back and forth, one of the biggest problems we are having right now is dividing the works into manageable chunks and work collaboratively through specs and APIs. Ideally being different committees will not prevent two sides from working on the same feature anyway, since there will be an agreed spec. I think this can be achieved by coders who work on the same features from same side meeting. This can be done by assigning a project manager to the feature, from the archive committee.

My main beef with subcommittees is that as much as we try, the way we do them, they lack the autonomy from their committees, chairing authority, board support. This would harm separation of these tasks which in turn would be harmful for volunteers for the reason I mentioned above.

Does this answer your questions or do you still think they should be combined? I know it is not a clear cut decision as splitting design and QA but I personally think that the pros outweight the cons.
From:
Anonymous
OpenID
Identity URL: 
User
Account name:
Password:
If you don't have an account you can create one now.
Subject:
HTML doesn't work in the subject.

Message:

If you are unable to use this captcha for any reason, please contact us by email at support@dreamwidth.org


 
Notice: This account is set to log the IP addresses of everyone who comments.
Links will be displayed as unclickable URLs to help prevent spam.

Profile

eylul: (Default)
eylul

October 2012

S M T W T F S
 12 3456
78910111213
14 151617181920
21222324252627
28293031   

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Aug. 23rd, 2017 01:36 pm
Powered by Dreamwidth Studios