absolve dev mailing list?

[Mike Nereson]

A thought, should the dev mailing list be absolved since this project's community is so small? Sometimes too many options can be a hindrance to growth. We could keep all discussions in the users list.

Thoughts, comments?

~ Mike Nereson

[Mykola Nikishov]

"Mike Nereson" <miken...@gmail.com> writes:

> We could keep all discussions in the users list.

+1

--
MAN-UANIC

[cda...@gmail.com]

I'm good either way. If you decide to shutdown the dev list we should
come up with a subject convention so that users can tune out dev-only
postings. Maybe something like [DEV].

[Mike Nereson]

Thank you both for your input.

I'm thinking that at the current level of discussion, we don't even need to denote DEV. I get usually about 1 personal email every 2 months. Almost nothing even goes to the user list.

I am not going to make any changes soon, I was just throwing that out there to see what you thought.

Thanks, guys.

~ Mike Nereson

[Raja S]

Hi Mike,
 In my opinion, lets continue to have the dev mailing list if it is not adding any overhead.

Meanwhile, I was going through the classcycle code as an alternative to JDepend.   I was also googling for similar types library available, so that we can the correct choice.

If any of has got any other links kindly mail them so that I will have a look at them as well before moving away from JDepend.

Regards,
Raja

[Mike Nereson]

Raja, good to hear from you again.

There is no additional overhead since its already in place. The only concern that I have is making this information easy to find. I have 6 or 7 different pages that direct the users to the mailing list, so I hope they are easy to find, but who knows. I just want to do what I can to help this very small community grow. Thanks for your vote. Since we ended up with a 2 for and 2 against, I am going to go ahead and just leave the dev list in place.

Regarding alternative to JDepend, I have a page on the architecture rules website that lists some alternatives to Architecture Rules. This list has grown over time as individuals have brought these tools to our attention.

http://72miles.com/architecturerules/alternatives

Some are complete solutions, like architecture rules, that would not be good for extending, others however, like JDepend or Classcyle are prefect for extension. So you can check out that list, and if you find any others, we can add it to that list.

Speaking of adding to the list, once we get the new domain, architecturerules.org, I am going to setup a mediawiki instance and a new wordpress instance. The mediawiki will be for documentation and the wiki format will allow all of you to help add new information, and update old information. The new wordpress blog will allow all of us to post on archtiecture rules-related topics including new development, interesting isssues that we find and solve, tutorials, and release annoucements. I have a ton of posts on my blog ast 72miles.com/blog on architecture rules that I plan to migrate over. So if you're into blogging and have anything interesting about architecture rules that you've found or want to talk about, start thinking about how you want to write that up ( :

~ Mike Nereson