2008年03月23日 星期日

Exco blog and Jira are up today

This is the first post. Thanks Google for providing the google app and blogger.

This blog is for logging the works of the HKJUG exco as record. It's not an official communication channel, and I plan to setup an official blog at our hkjug.org website for things like event announcement.

For today, we've got:
  • This blog site @ http://blog.hkjug.org

  • Google app - we've moved our email to Google App, and the other Google App features like calendar, docs etc. are available to us.
    • www.hkjug.org is currently hosted in Google. It is planned to move to our own server.

  • JIRA Issue tracking system @ http://issue.hkjug.org . It's up and running and everyone can register an account and watch our works.

10 意見:

Rob 提到...

I had previously created a Google Calendar for HKJUG events here; iCalendar feed here.

Mingfai, you should already be able to add events, assuming your hkjug.org email address is working. Not sure if you want to use that calendar, or create a new one under the HKJUG Google Apps domain.

Mingfai 提到...

I haven't thought about calendar yet. If the existing calendar has a lot of data in it already, then it's good to keep. But if there are not too much event anyway, it's better to move to the hkjug.org calendar.

My priority is to setup a wiki site for http://hkjug.org . I wish to use XWiki Workspace in long term, but probably I'll use Confluence in short term.

I'll contact you later about the calendar. Thank you.

Rob 提到...

> If the existing calendar has a lot of data in it already, then it's good to keep.

It has every event since last December. In other words, one. :)

> My priority is to setup a wiki site for http://hkjug.org . I wish to use XWiki Workspace in long term, but probably I'll use Confluence in short term.

How hard will it be to migrate the content to XWiki if the Confluence wiki is successful?

Mingfai 提到...

let's think about the calendar later. :-)

re. wiki. all wiki platform does not speak the same language. (most wikis have their own syntex) so porting will mean moving content page by page. Given that there won't be many pages, there is no issue at all.

Let me address it in another post.

Rob 提到...

> Given that there won't be many pages, there is no issue at all.

Come now, let's not underestimate the enthusiasm of Hong Kong Java users... :)

Blog of calendarw 提到...

I have few question:
1. could JIRA support OpenId?
2. could proposed wiki support highlight syntax?

Mingfai 提到...

>I have few question:
>1. could JIRA support OpenId?
no. http://jira.atlassian.com/browse/JRA-13942

>2. could proposed wiki support >highlight syntax?
Do you mean syntax highlight of Java programming code? this is a highly desirable feature. Confluence does support syntax highlight of Java code.

The Wiki "project" refers to two things, one is for HKJUG to publish content, the other is for members to register and write their own wiki pages. I don't really want to open Confluence for the 2nd usage. We got license for 500 users only and it might be a nightmare for me to clean up the unused user accounts.

Rob 提到...

> We got license for 500 users only and it might be a nightmare for me to clean up the unused user accounts.

Presumably the licenses are needed only for editing pages, not for viewing pages, right?

Do you really think we are likely to get more than 500 people who need to edit pages?

Mingfai 提到...

>Presumably the licenses are needed only for editing pages, not for viewing pages, right?

every time anybody register an account, it consumes a license.

>Do you really think we are likely to get more than 500 people who need to edit pages?
obviously there is no chance to have 500 editors. but when we offer it for free and allow public registration, it's not difficult to get 500 users. Then I will need to manually check who are real user and who are just dummy account. It's the nightmare I referred to.

Rob 提到...

> every time anybody register an account, it consumes a license.

Right. But do they need to register to view pages, or just to edit? (In my experience people are unlikely to register unless there's a clear incentive.)

> obviously there is no chance to have 500 editors. but when we offer it for free and allow public registration, it's not difficult to get 500 users. Then I will need to manually check who are real user and who are just dummy account. It's the nightmare I referred to.

Any way to require that new accounts are approved by an admin, to avoid spurious account creation?