On Jan 3, 2007, at 7:41 AM, Mark Brouwer wrote:
Geir Magnusson Jr. wrote:
I would expect to see the process here 1) discuss idea on the
list 2) open
JIRA ticket 3) add patch to ticket and subsequently refer to the
ticket
number in discussion.
Yes. And I think that there's no requirement for a committer to
open the JIRA, really.
Maybe it is because I have to get acquainted with your way of writing
Geir ;-), but from the above I can't make up whether you think
committers can hack around without opening a JIRA issue,
yes, committers can commit code w/o opening a JIRA issue.
or that you
think that in most/many case the process lined out by Phil should be
followed.
I think it's a good start to talk about, and expect this community
will work out it's own working style.
I think the key thing is finding a balance between :
1) communication and transparency (e.g. discussion on the dev list)
2) few roadblocks for getting things done (e.g. commit then review
(CTR))
IOW, you don't want to serialize all changes through discussion on
the dev list, but by letting your fellow community members know what
you are up to ("Hey, I'm working on refactoring the
frobnosticator...") it gives them a chance to engage with you ("hey,
I have some ideas too, let me help") or raise a flag for discussion
("You can't - we've committed to that interface last version....").
Thats the communication side. On the CTR side, you have a safety net
for cases where you didn't tell people what you were doing (you were
heads down on a project and modified some related things...) or did,
and people weren't paying attention.
I think of it as optimistic locking on the code...
JIRA is great for tracking, but there are things to be cautious of -
I've experienced technical discussion moving into the JIRA itself,
which I think is not good, because it loses the bigger audience
(IMO). I hate having to read JIRA discussions on the JIRA-generated
emails, and it makes it hard to participate offline (unlike email) or
search (unlike email...)
geir
