Hi everyone
Now that we've got 14 developers with CVS rights, and we've recently
introduced JIRA, I wish to propose some project management procedures.
These are aimed at making life easier for all of us, and helping the
community to understand our approach to different matters (particular if
running from CVS HEAD). Most of them are based on what is already
happening, yet it seems worthwhile to list them in a single email so
there is some reference.
I invite discussion on these procedures if the community feels there
might be better ways of achieving these objectives. After a period of
discussion, we can implement the finalized procedures. The proposals are:
1. JIRA for this project is located at
http://opensource.atlassian.com/projects/spring/secure/BrowseProject.jspa?id=10040.
Please log a task in JIRA for any changes you make to CVS, with the
exception of very minor changes that users are unlikely to ever be
interested in searching for and/or the change affects code that has
never been in an officially released version of the project (eg ongoing
changes to a new feature in CVS HEAD that hasn't been released previously)
2. Any users running from CVS HEAD are warmly encouraged to join
acegisecurity-cvs so that they can keep an eye on commit comments.
Developers are encouraged to join acegisecurity-cvs and read the commit
comments. If anyone has a concern with any commit, please raise it on
acegisecurity-developers so that the broader community can participate
(not acegisecurity-cvs). Alternatively, contact the author of the change
directly if you think that would be more appropriate or diplomatic.
3. Please make your commit comments informative, yet not too detailed.
Detailed comments are ideally placed in the JIRA task. In the case of a
contribution by a non-developer, please use the CVS commits to reflect
who provided the contribution and add that person's name to /project.xml
in the contributors section. If the contributors section does not list
the name of someone who has contributed accepted code, please add them
or let me know so that I can do so.
4. If you add a major new feature, please announce it on
acegisecurity-developer. That way people using the project have an idea
of what is coming up in the next release, and any
implementation-specific comments can be received prior to the first
release when users will start expecting some degree of consistency and
stability. It also encourages people to try out your new feature.
5. Please edit /docs/xdocs/changes.xml to reflect any changes you
commit. The entry should be short enough so that I can copy it into the
new release announcement email, and reflect the JIRA issue number if
appropriate.
6. Please edit /docs/xdocs/upgrade/upgrade-xx-yy.html if you make a
change that is significant and you think users who are upgrading should
be aware of it. Equally, users are encouraged to consult the
upgrade-xx-yy.html file before they deploy subsequent official release JARs.
7. Please use Jalopy with the /jalopy.xml file to format your Java code
before checkin. This keeps our code consistent and ensures the license
message is correct. There are plugins for all major IDEs.
8. The /sandbox can be used to obtain feedback from fellow developers
and the community about your code, general approach or new ideas. If you
have CVS rights, please use /sandbox instead of emailing ZIP files to
other developers for feedback. The community should understand that code
in the sandbox is unsupported, subject to refactoring, may not have any
unit tests, and may be removed at any time. The /sandbox will never be
included in official release ZIPs. It's a "scratching pad" only.
9.Unit tests are important to any security project, and we have a good
history of high coverage. You can view the latest coverage report
(rebuilt every 24 hours) by visiting
http://acegisecurity.sourceforge.net/multiproject/acegi-security/clover/index.html.
Please keep an eye on coverage and don't hesitate to add more unit
tests. Please do not check code into /core unless it has at least an
exercising unit test - use the /sandbox instead.
10. Never check in code if the unit tests fail. This means, at minimum,
successfully running "maven test:test" from /core. Always name your unit
test classes so they end in "*Tests" - this ensures that Maven picks
them up. If there is code in CVS which you didn't write and it is
breaking the unit tests, please correct it yourself - don't leave CVS
"broken" whilst waiting for the responsible developer to address it (the
delay causes confusing and long-running threads on the list and forum).
You can always rollback to the previous working version if in doubt of
how the class works (just remember to comment the commit appropriately
and let the author know).
11. Please update the reference guide and JavaDocs for any new major
features. The JavaDocs should always be correct. The reference guide may
be kept updated with less rigor, although please briefly discuss any
major new features. http://www.xmlmind.com/xmleditor/ can be used if you
don't have a DocBook editor.
12. Developers please keep an eye on the Acegi Security forum at
http://forum.springframework.org. It's a very active forum, and it takes
a lot of work if not shared around. Please don't hesitate to reply to
users - I generally will read every post and correct/confirm the
situation if someone mentions they're unsure. I also will generally send
developers an email if there's a question I can't answer as I didn't
write the code.
13. In the future, I will put to vote any proposed new developers. New
developers will be firstly encouraged to attach patches to JIRA tasks to
illustrate their understanding of the project, or, if they're long-time
users, they might be given access without this JIRA stage if they're
undertaking a major new feature.
14. Developers should be subscribed to acegisecurity-developer.
Obviously it would take significant time to read every thread, but
reading the high priority messages (as indicated by the subject line) is
needed to ensure we all have a way of communicating.
15. Please do not hesitate to assign yourself any JIRA task that is
unassigned, or assigned to me and not in the "In Progress" status. Also
feel free to approach fellow developers to volunteer to work on tasks
they might be assigned but haven't started.
16. No code in CVS is "sacred". If you have a good idea or refactoring
for an area of code that someone else wrote, raise it on
acegisecurity-developer or contact the author directly. Please don't
commit changes to such code unless it is a unit test failure correction,
or you've firstly raised it on the acegisecurity-developer list or
directly with the author.
17. People's priorities are ever-changing, and we're all short on time.
For this reason it's perfectly understandable that over time developers
will move on to other things. This is not a negative reflection in any
way - just part of any long-term project. If a developer no longer has
the time or inclination to participate in the project , please send an
email to acegisecurity-developers or myself. I will remove the CVS
rights and reassign any JIRA tasks. Importantly, this helps find a new
maintainer of the former developer's code (or, in very extreme cases,
their code might be relocated to the sandbox or removed).
18. Keep the warm community spirit. The Spring community is a nice place
to be - especially compared with some of the other open source
communities out there where people are abused, ignored, insulted or
excluded. No policy or procedure (including those above) should ever
compromise operating in a considerate and diplomatic manner that
respects the dignity of each individual member of the community. If in
doubt, please contact me directly first. If I am ever guilty of this,
please let me know and I will correct myself.
Comments are welcome.
Cheers
Ben
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Home: http://acegisecurity.sourceforge.net
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
